Re: [dev] reboot, arrow in the knee because of the GNU GPL???
Hi Sylvain! You must be new here. People on this list mainly lurk watching progress of suckless software. There are two kinds of threads here: 1. Patches and development of suckless software - strictly technical. 2. The rest - recommendations/questions for/about suckless software/distros/protocols/licenses - nothing constructive came out of them ever. Your thread is one of the rest. Most prominent and active members of this community have basic approach of "shut up and show me the code". Licenses are not code. Dnia 2014-06-26, o godz. 05:15:53 Sylvain BERTRAND napisał(a): > I firmely disagree with you on this: the event of somebody hurt > by the GNU GPL with real life facts is of highest importance for > all open source coders. And communication would have been > an enrichment for the suckless community. > The thread will die because I think those facts do not exist. This issue may be of highest importance for you, but it seems that you are quite alone among this community. Most people here want suckless software - written in C and Shell not in legal english. MIT license is good enough. I share similar views on GPL as Rob Landley and I belive that many members of this community, which don't like GPL share similar views (maybe without Android sentiment). Few links: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3 This relates with me, but I suppose less with others (GPL good for Linux kernel): http://landley.net/notes-2008.html#14-12-2008 http://landley.net/notes-2011.html#15-08-2011 http://landley.net/notes-2011.html#16-12-2011 Here is quite cool idea about patentless public domain: http://landley.net/notes-2014.html#10-04-2014 http://landley.net/notes-2014.html#19-04-2014 If you would like to counter with arguments or links - don't bother. You're the one asking for information. With regards, Hadrian Węgrzynowski.
Re: [dev] Lightweight, non-bloated, fast image viewer?
Dnia 2014-06-14, o godz. 14:52:39 FRIGN napisał(a): > On Sat, 14 Jun 2014 12:42:00 +0200 > Markus Wichmann wrote: > > > So, having one program that reads some standardized input and > > displays it on screen, while another program converts any given > > image file to that standardized format may be more UNIX-like. But > > maybe a file is not the right representation for that standardized > > format. So maybe the converter would need to be a library instead > > of a program. > > This is a very nice idea. What any image-lib basically does for > internal representation is to load the image as a bitmap. > An image-viewer for bitmaps piped by a converter for the common > formats would be a good idea. Pure suckless image viewer is indistinguishable from suckless drawing stack or suckless window server. That's how I see it. You can try to make simple image viewer or simple window server. You have to draw the line somewhere.
Re: [dev] [st] Feature to replace st window by spawned x window
Dnia 2014-04-28, o godz. 17:17:56 Nick napisał(a): > Esteemed comrades, > > I remember reading ages ago about how graphical programs launched > from Plan9's terminal thing (/editor/whatever) replace the window > it's in. I would really love a patch for st to do the same. So I > could type 'mupdf mything.pdf' and mupdf launches in the same window > as st was inhabiting, with st magically returning once mupdf exits. > > Does someone with more knowledge of X11 know whether this is likely > to be readily do-able? Can you launch an arbitrary X program and say > "use this window"? I'm guessing not, but don't really know. > > There are disadvantages to this approach, the main one being hiding > stdout & stderr. But I still think it could be interesting. > > Nick > It's possible with X11 proxy and tabbed. I experimented a bit in this area. Proxy basically changes root window for it's clients to specified window (e.g. tabbed). So I called it chrwin (change root window). Example: chrwin fakeroot-xid [program arg1 ...] $ chrwin `tabbed` st Ideally it should work in that way: 1. On start chrwin checks root window id. 2. Creates socket for proxy, sets DISPLAY and optionally proper xauth. 3. For every client's create window request with parent xid same as real root window: 3.1. Change real root xid to fake root xid and send this to X11 server. 3.2. Send to client reparent notify with fake root xid. It should also check for window type (it's in separate request), because dialog boxes etc. shouldn't be reparented. Tabbed can hide it's tab bar. As noname said it's not possible for every program out there such as multi-window programs. I didn't have time to finish such proxy, but I have WIP (it's all hardcoded and it worked): http://hawski.com/chrwin/chrwin.c
Re: [dev][ubase] Implement switch_root
Dnia 2014-04-13, o godz. 14:10:51 FRIGN napisał(a): > Good day, > > sometimes, you depend on an initramfs to do stuff for you before > the rootfs is available. > Busybox has become the standard for "all your initramfs needs", but > tbh, I hate working with it. > Statically linking sbase and ubase and choosing the tools you need for > the job almost solves the problem, but the lack of switch_root, which > almost every initramfs depends on, forces you to use busybox (because > util-linux doesn't link statically). > > Now, I would've already sent in a patch, but I am pretty sure somebody > here already hacked it together before. So, to save my time, I better > ask now. > > Cheers > > FRIGN > Toybox has implementation of it: http://landley.net/hg/toybox/file/43c3d6350b38/toys/other/switch_root.c
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Dnia 2014-02-21, o godz. 21:54:59 FRIGN napisał(a): > A semantic web-browser is a great idea. It has already been partially > realized in links. If X-support is compiled in, you can test it out > with "lynx -g". > It's blazing fast (!), but sadly gives insight into how unsemnatic the > web has become over the years. > > Cheers > > FRIGN Sometimes I am amazed how many sites work properly in links. I never succeeded with javascript enabled VT browsers though.
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Dnia 2014-02-21, o godz. 14:53:22 Charlie Kester napisał(a): > On Fri 21 Feb 2014 at 13:15:24 PST Hadrian W?grzynowski wrote: > > > >Even if it would work, I think that web shouldn't be pixel-perfect, > >because we could just use some glorified-PDFs. It's utter nonsense > >that correct rendering of page is depending on some specific font and > >specific font size. It's utter nonsense to not restrict paragraph > >length (at 80 characters or something). It's utter nonsense to assume > >that everyone is using maximised browser window at 1080p. > > I'm an old fart who never got into web programming, so forgive me if > this is a stupid question: isn't the rise of smartphones and other > mobile platforms forcing people to abandon those assumptions about the > screen sizes they're working with? (As, for example, epub vs pdf.) > > Or is the trend to create a separate, "mobile" version of the page, > which simply changes the assumption to some smaller screen size? > > Or are people just ignoring the problem altogether? Because of compatibility mobile browsers pretend they are like desktop browsers. They move around the problem by scaling [1]. So problem is mostly ignored. Some sites create special mobile version. Sometimes it's crippled version of site or quite sane version which can better than desktop. [1] http://upload.wikimedia.org/wikipedia/commons/2/23/Nokia_Mini_Map_Browser.png
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Dnia 2014-02-21, o godz. 13:27:51 Ryan O’Hara napisał(a): > On Fri, Feb 21, 2014 at 1:15 PM, Hadrian Węgrzynowski > wrote: > > It's utter nonsense to not restrict paragraph > > length (at 80 characters or something). It's utter nonsense to > > assume that everyone is using maximised browser window at 1080p. > > > > 80-character paragraphs don’t sound particularly semantic. > With semantic paradigm browser can safely wrap lines of paragraphs and nothing will explode. Currently many pages have too long lines in 1080p and many pages have too short lines in 800p.
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Dnia 2014-02-21, o godz. 16:21:22 "Dmitrij D. Czarkoff" napisał(a): > > Thus, rendering issues are either originating from bad > > browser-defaults or faulty CSS. > > I don't even touch CSS. And I just can't see any valid argument for > existance of browser-defaults – the format that is supposed to deliver > pixel-perfect rendering for given screen size the very fact that there > is something left for browser to decide is already complete and utter > defeat for the whole markup language. There should be separate stack for pixel-perfect device independent use and for semantic web (without CSS and JS), but then semantic web would probably just die... Even if it would work, I think that web shouldn't be pixel-perfect, because we could just use some glorified-PDFs. It's utter nonsense that correct rendering of page is depending on some specific font and specific font size. It's utter nonsense to not restrict paragraph length (at 80 characters or something). It's utter nonsense to assume that everyone is using maximised browser window at 1080p.
Re: [dev] Re: Reasonable Makefiles
Dnia 2014-02-11, o godz. 20:15:06 Thorsten Glaser napisał(a): > “Re: *** GMX Spamverdacht *** [dev] Reasonable Makefiles”. > Honestly! > > > Markus Wichmann dixit: > > >A typical Makefile of mine looks like this: > > Ugh, a horrid GNUmakefile… I normally write: > > PROG= foo > > .include And now you're using another unportable way to include files. Although pmake is nicer than gmake. Recently I started development of simple make implementation. My goal is to be able to 'make' suckless makefiles. Plan is: if something will be correct for my make it must be correct for gmake and pmake also.
Re: [dev] Announcing sinit - the suckless init
Dnia 2014-02-06, o godz. 12:32:59 sin napisał(a): > Hi all, > > As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on > Strake's init[2]. > > It is currently controlled via a FIFO. It supports only two commands > (reboot and poweroff). > > It follows the classic style of config.def.h and it should work with > any init scripts. I've been testing it with my init scripts[3]. > > Let me know what you guys think, I am looking forward to use this > with sta.li. > > Thanks, > sin > > [1] http://git.2f30.org/sinit > [2] https://github.com/strake/init > [3] http://git.2f30.org/fs/ > Hey. Did you saw qinit[1] from David Galos? It seems that some of ideas overlap and some features could be reused, like "reload" on fly. [1] http://galos.no-ip.org/qinit
Re: swc library to implement dwm under Wayland (was Re: [dev] gtk3 support for surf?)
Dnia 2014-01-14, o godz. 11:42:14
FRIGN napisał(a):
> Yes, that's true. However, you need to stress here that Wayland is
> just the protocol implementation for communication between clients and
> server and glue-code between clients and EGL-calls.
> It doesn't pull in the big libs itself, but _implicates_ a compositor
> (server) using EGL to communicate with Mesa 3D.
> On the client side, same applies.
>
> You can't do Wayland without EGL.
EGL as API is quite lean. There could be small implementation not
depending on Mesa 3D.
Is there another problem with EGL?
> Now, where's the problem?
>
> -1) Compositor's demands:
> Not everyone has a full drm-kms-setup. Hell, I don't even use evdev
> on my devices (It's more secure when you strip out the Event Interface
> from the Kernel).
>
> The biggest factor here probably is Mesa 3D. You just don't want this
> overhead if you don't intend to spend most of your time playing around
> with 3D-effects and burning windows.
> Given the direction the mainstream-Linux-desktop is going, Wayland is
> the appropriate answer.
>
> However, having looked into the topic a bit deeper, I basically found
> the Wayland-Compositor-Client model to be very similar to what you get
> implementing a GUI into a video-game[1] combined with several
> util-functions to set _basic_ things up.
>
> Yeah, I know Wayland doesn't require OpenGL(ES), but guess what most
> compositors build upon.
I am just curious:
1. Can Wayland clients use just simple blitting without special kernel
infrastructures?
2. Can Wayland Compositor work without special kernel infrastructures?
3. Are Wayland clients using evdev or is it just for server?
4. Does anybody know how good is pixman library (AFAIK software renderer
used by Weston)?
> -2) Code-rot:
> The Wayland protocol itself may be very lean, but that's not where the
> big overhead comes from. It rather is the fact you need to rewrite
> trivial features like evdev for each new compositor you chose to
> develop.
> I know, there are libs, but who guarantees they're still around in a
> few years _and_ compatible with the still rather "dynamic"
> Wayland-API? Why not just write a Weston-plugin then? Because Weston
> sucks (PAM, overengineered, too many features for dwm, ...)!
I like to think that, we could make up compositor from few buildng
blocks, but I don't know Wayland that much to know is this viable.
> In the end, you just give up and implement it yourself, forcing you to
> maintain thousands of LOC, risking bugs and wasting your time.
$ find swc -iname "*.[ch]" -exec cat '{}' \; | wc -l
8350
$ find tinyxserver -iname "*.[ch]" -exec cat '{}' \; | wc -l
235126
> -3) Window decorations:
> It was noted before, but window decorations are not trivial with
> Wayland.
It is true, but in case of dwm decorations are relativly trivial.
> -4) Sucklessness
> What should we do then?
> My advice would be to take a look at tinyx[2] and tinyxlib[3], which
> is relatively small and fitting the purpose well (dwm runs on it).
That is cool nevertheless.
> Let's see what the future will bring us, but it now is all about
> making a decision.
Even if Suckless Wayland Compositor can be successfully implemented
suckless most probably will not abandon X11 for the foreseeable
future, which I think is good.
Truth is - we can talk, but only written code matters.
With regards,
Hadrian Węgrzynowski.
Re: [dev] portable photoshop-like lite application based on C?
Hi, On 2013-12-02, 12:00:10 Calvin Morrison wrote: > You can do quite advanced image manipulation with something like > ImageMagick. That can be very powerful. Many times it's also quite intuitive. I would prefer separate tools for most of the actions though. I would like to have something like xsel [0], but for graphics. Then I could copy image from web browser and use it easily in CLI. > I actually like prog21.dagum's ideas [0] (no idea who he is), a purely > functional, non destructive editing program That's also how I would see it. > Here would be my idea: A scripting window for commands, a graphics > window which shows the image buffer, and also allows recording of > mouse actions (as to script functions like select) This is similar to one of my ideas about such program. I would also like to see this as a graphical shell with a graphical terminal. If this would be reasonably fast it could be also used as a base for suckless GUI toolkit. Of course input handling remains. How such suckless GUI toolkit could be implemented? Maybe VFS? Maybe for start just a X program using stdin/stdout? [0] http://www.kfish.org/software/xsel/ With regards, Hadrian Węgrzynowski.
Re: [dev] Some thoughts about XML
On Fri, 18 Oct 2013 14:44:55 +0200 Szymon Olewniczak wrote: > At the and I want to ask you a question. What do you think would be > the best solution for bulding websites which would look similar to > this what we have now(gopher is great but ...) and would have easily > accessible data for persons who want to use it in thay own > applications? Hi. It's impossible. Either you have application, or you have document. Websites of today want to be applications with precise visual representation. Website's design can blow up if you even change the font size. There should be separate web for applications (with something more appropriate than HTML/CSS/JS). There should be also separate web for documents (with something more appropriate than HTML/CSS/JS). I don't see any worldwide hope soon. XML+XLST certainly is not one. There is too much push for more brands and APIs, than for simple interaction between programs.
Re: [dev] Talk about suckless
On Wed, 25 Sep 2013 20:13:11 -0400 Alex Pilon wrote: > On Wed, Sep 25, 2013 at 02:26:08PM +0200, Martin Kopta wrote: > > Talk description is (translated): > > > > "Introduction to ideology of software that smells less and > > presentation of results of the suckless project. Demostration of > > dwm window manager, > > Don't just demonstrate. Try to prove that a dynamic window manager is > overwhelmingly superior to the current inefficient paradigms. Don't > forget to mention low dependency count, and quick compilation times. You can mention that tiling paradigm came back with smart phones, Windows 8, GNOME3, Unity and earlier with Aero-Snap. You can then make some comparisons and point out differences. > > terminal emulator st, > > Any theme in particular? *Straightforward* hackability? Comparison to > xterm or whatever is shipped by default in favourite distro X? > > minimalist web browser surf > > Make a point about practical usage. You can talk about tabbed in case of surf, st and general case. > > Is there something I absolutely shouldn't forget to mention? That suckless software as is is not for everyone, but easily you can use that software as foundation to build upon. With regards, Hadrian Węgrzynowski.
Re: [dev] suckless dotfiles approach
On Sat, 08 Jun 2013 00:28:14 +0200 Markus Teich wrote: > Hey guys, > > I feel this three popular approaches have drawbacks: > * When creating the repository in $HOME i have to carefully select > which files to add. > * When copying files from the working directory to $HOME i have to > sync the working directory with $HOME manually (no 'git diff' or 'git > status'). > * When symlinking files i get problems when moving/backing up the > configfiles in $HOME since it will move the symlink and maybe write > an actual file to $HOME instead. > > Which seems to be the most suckless to you? > > --Markus > The most suckless would be to use software that don't need dotfiles or don't need it much. I try to have my dotfiles as small as possible. Using software that have sane defaults also helps. Then it's not very hard to keep them in sync using whatever method you prefer.
Re: [dev] Re: Why HTTP is so bad?
Dnia 2013-05-27, o godz. 23:32:48 Dmitrij Czarkoff napisał(a): > On May 27, 2013 11:13 PM, "Nick" wrote: > > > > Netsurf's rendering libraries are pretty suckless. But they don't > > have at all complete javascript / dom support yet, so it's only as > > useful as lynx (which is to say, rather useful, but not for > > everything that is convenient to do on the web). > > NetSurf basicly only supports HTML and CSS2 (with some portion of > CSS3, but far from being complete or on par with Webkit or GECKO). > Indeed lynx is a better choice in most cases. > > Still, there is quite a lot of overengineered websites that require > JS (one of the sites I have to use regularly uses JS cookies for > session stuff), and neither lynx nor NetSurf are of any use there. > > FWIW there still quite a lot of browser-specific quirks here and > there, even including browser-specific tags, which defeats the very > idea of suckless rendering engine. > > > Dmitrij D. Czarkoff I like to think that suckless browser should render web in readable and useful way, not adhere to all standards. For example support only two fonts: monospace and proportional. Only partial CSS support is needed. Problem starts with JS.
Re: [dev] Re: Why HTTP is so bad?
Dnia , o godz. Random832 napisał(a): > On 05/25/2013 12:55 AM, Strake wrote: > > Yes. Thus I can easily swap out any component, or insert mediators > > between components. For example, I could write my own fetcher to > > scrub the HTTP headers, or block ads; and I wouldn't need plug-ins > > to view PDFs or watch movies. > Why is the requirement that it conform to your IPC protocol* less > onerous than requiring it to conform to a particular in-process API > that would make it a "plug-in"? It's as bad idea as implementation of shell commands as plug-ins to shell. > *which has to handle navigation on both ends, A] what happens when > you click a link in your viewer and B] what happens to your viewer > when the user navigates away from it. Also, is the browser required > to download the whole file before opening the viewer, or can for > example a PDF viewer display the first page before the last page is > downloaded? Also for large files (highly relevant to a movie viewer) > with a file format that allows it, you could take advantage of range > fetching, but in both of these cases the viewer has to speak HTTP and > just be told a URL by the navigation component. Maybe we could make it work with something like httpfs [1] [1] http://httpfs.sourceforge.net/
Re: [dev] [suckless] Migration to git
On Mon, 26 Nov 2012 11:25:18 +0100 Christoph Lohmann <2...@r-36.net> wrote: > Greetings comrades, > > I am proposing a migration of all mercurial to git repositories. Git > is mature and used by nearly all major OSS projects. Mercurial > has this slow prototyping dependency of Python, which is annoying > and could be removed that way. Of course git is still(?) adding a > perl dependency. I hope this can be removed from git. > > My proposal is to rename hg.suckless.org to git.suckless.org. > There might be some other (better) versioning system in the future, > which will need another domain. Only the hard reality of > »Connection refused« forces a fast migration. > > Dpb on IRC showed me [0], which seems to do a near to perfect import > of the old hg history. Anyone had bad experiences with this? > > For the web interface on git.suckless.org I am proposing cgit, which > is fast and written in C. > > How are your thoughts, comrades? > > > Sincerely, > > Christoph Lohmann > > [0] > https://raw.github.com/felipec/git/fc/remote/hg/contrib/remote-helpers/git-remote-hg > > As Kurt asked earlier - what for? Because it sucks a bit less? I'm more git user myself, but hg is OK. Even if git sucks less, so what? I thought that people here value their time more. Changing tools as soon as something is becoming 'suckless' sucks. As stated before, maybe it would be better to pursue better hg implementations? People here are always interested with code, good code. Curing one disease with another is not really helpful.
Re: [dev] Minimal distributions
Dnia 2012-11-25, o godz. 15:54:40 Hugues Moretto-Viry napisał(a): > Thank you for your constructive answer. Actually, I looked this page > but I think many distribs are missing, just because they're not known. > That's why I asked this question. I thought some persons use > something I don't know. > > I think you misunderstood me about "No need to talk about...". It was > related to Gentoo and Slackware I already know. > I wanted to avoid unpleasant comments like "Use google & you'll find > Gentoo". > Your opinion still interests me. I can tell you that I was searching for something like you described. After few years of using Gentoo I can't stand it any more. I was using one Ubuntu box, but it's like bad parts of rolling release with bad parts of versioning release. I was living with testing packages for all, but that was stupid and tedious. Later I switched to stable, but that was also stupid and still tedious. Finally I got to conclusion that rolling release can only really work for minimal installation or "real system" - not distribution (packages thrown together glued by some package manager). It's so much better to have simple versioned core and then manage few special applications yourself. Do you really need to have always the latest Xorg, coreutils, mplayer and other basics? There are of course some things that you will need to have at some specific version (often just the latest). How many? If it is some library it's probably easier to clone the repository and keep updating. If it is some application, that you use professionally, you are keeping track of version changes already. To know what will happen to you soon. If you need some bug-fixes or features from next versions your distribution most probably will not have nightly builds or latest version from VCS. Gentoo will have these for some packages, but you can't really count on them. I prefer "real systems". There should be core that I can always count on and some packages available. If there is specific package needed I get the code from VCS (as I was doing already in Gentoo - the rolling release distro). I am running one Slackware box now and I like it. It's quite simple and consistent. Upgrade from one version to another is pretty painless. I can get additional packages with slapt-get or sbopkg. It's OK. Some people are using pkgsrc with Slackware. If you need minimal installation and not much more even Gentoo should be OK. Slackware should be more then OK. That's the only recommendation that I can honestly give you. Other then that, I would consider for such system (in particular order): one of BSDs (primarily FreeBSD), TinyCore (maybe with some additional package manager), Sorcerer. Never tired any of them. Probably all of them can be used as rolling release (CURRENT versions etc.). > And for GNU, it's kinda a language abuse. I try to not forgot GNU > when I talk about Linux. GNU is not liked here ;)
Re: [dev] Minimal distributions
Dnia 2012-11-25, o godz. 21:16:17 KarlOskar Rikås napisał(a): > On Nov 25, 2012 9:02 PM, "hiro" <23h...@gmail.com> wrote: FUCK OFF > THEN > > Sure, I thought suckless's community had a common sense how to > behave, good bye. It is not a community, it is interest group.
Re: [dev] Minimal distributions
Dnia 2012-11-23, o godz. 19:53:36 Hugues Moretto-Viry napisał(a): > Hi there, > > Just because I'm really curious, I'm searching minimal GNU/Linux > distributions with the following options: > > - x86_64 architecture > - minimal installation > - no default Desktop Environment > - rolling release > > Someone talked about another distrib' on a previous subject, but I > cannot find it. > You can tell me I should use Google instead of asking you, but I had > many foolish or similar results. What interests me, it's your opinion. > No need to talk about Gentoo, Slackware or Debian, I already know > those distributions. > > Regards What you want most probably does not exist. I'm quite sure that you've seen Wikipedia list of rolling release distros [1]. But somehow you aren't convinced. As seen previously in such threads there will be no helpful conclusions. You can prepare for: "everything sucks", "you suck" or "make your own". Do you want minimal installation as in minimal installation and big available software repository or as in minimal installation and not much more? If the former you already know that you can choose only from derivatives of popular distributions. If the latter can you really expect satisfactory rolling release model? You want "our" opinion, but there is "No need to talk about (...)". Maybe there is not a lot more to say then? GNU/Linux distribution that you would like does not exist (yet?). [1] http://en.wikipedia.org/wiki/Rolling_release#Rolling_distributions:_examples
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] uriel is gone
On Sun, 14 Oct 2012 17:14:11 -0400 Kurt H Maier wrote: > Sorry to have to let you guys know, uriel passed away peacefully a > couple days ago. We'll miss him. > > Kurt > I will miss his no-bullshit attitude. Sorry if I'm ignorant, but what will happen with cat-v.org?
Re: [dev] [tabbed] attach on demand
On Fri, 12 Oct 2012 08:07:55 -0300 Carlos Pita wrote: > Hi, > > I tend to open every surf instance (except for apps like gmail) in its > own tabbed instance just because I don't know beforehand if I would > need more tabs while navigating from the initial page. The ability to > attach (and maybe detach) to tabbed on demand would be very handy in > order to avoid this just-in-case usage pattern. Has anyone wrote a > patch like that? How do you use tabbed+surf? > > Best regards > -- > Carlos > I was thinking about something like this. Attach is quite easy to make using i.e. xdotool. Using script like this (untested): xdotool selectwindow windowreparent TABBED_ID Spawned by tabbed. Detach is reparenting window back to root window. After such operation reparented window is working quite normally, but inside tabbed remains nonfunctional tab. Probably quite easy to fix. Regards.
Re: [dev] Hall of shame of the web
Dnia 2012-09-30, o godz. 16:54:32 Bjartur Thorlacius napisał(a): > hiro wrote: > > that hall of shame is called google. we should all get back to using > > gopher or telnet. > > > Yes. Because Gopher and Telnet are superior to HTTP and SSH. > > /s > Gopher is superior to HTTP/[X]HTML[5]/CSS/JS/AJAX/Web2.0/KitchenSink.
Re: [dev] New friends
Dnia 2012-07-31, o godz. 16:16:43 Calvin Morrison napisał(a): > On 31 July 2012 16:14, Lee Fallat wrote: > > Yeah I saw this today as well and looks to be promising, but what's > > wrong with ALSA? :) > > > > > > ...ok fine you caught me, everything is wrong with alsa > > This is always a good laugh > > http://www.pc-freak.net/images/linuxaudio-mess-picture.png > > Calvin > I don't understand how is it different on any other major OS. There are always third party libraries.
Re: [dev] github mirror
On Wed, 23 May 2012 17:33:50 +0800 Kai Hendry wrote: >Nonetheless it would be great if you could help figure out the optimal >hg-git-hg work flow and tools required to pull it off. Or you could use hg directly. That would probably be the suckless way.
Re: [dev] st: improved double-buffering with Xdbe
On Fri, 20 Apr 2012 10:39:11 +0200 Brandon Invergo wrote: >Hi, >As some background, I've been using st on an Arm device (Genesi Efika >MX) which has relatively low specs compared to your average x86/amd64 >computer. st should be ideal because of how small it is compared to >xterm or rxvt but the reality is that its rendering is quite a bit >slower. Under heavy processor load, such as building a package, I can >literally watch the terminal window refreshing (ie I can see a line >traveling down the window, above which the window is refreshed and >below which the window is dirty"tearing"). > >I've changed the code to use the X Double Buffer Extension (Xdbe). >Instead of rendering to a Pixbuf and then copying that Pixbuf to the >window, which is a relatively slow operation, it now renders to an >XdbeBackBuffer and then simply swaps buffers with the window. The >result is tear-free and apparently faster rendering even on an 800mhz >Arm cpu. > >A side effect is that the code is a bit shorter as a result too. For >example, xresize() does almost nothing now, since the XdbeBackBuffer is >automatically resized with the window (see the DBE manpage), so several >Xlib calls can be removed from that function. > >The provided diff is against the default branch, however I also got it >working for the xft branch. I can provide a diff for that too if you >want but the only extra difference is that any Xft draw-related calls >should work on xw.buf rather than xw.win (including the one in >xresize()). > >LIBS in config.mk should have -lXext appended. I forgot to include that >in the patch. > >A few caveats: 1) my C skills are a bit rusty, 2) I'm unfamiliar with >Mercurial, 3) I'm completely new to Xlib. So, while it Works For Me >(tm), you might want to test it a bit and let me know if I messed up >something. > >I'm going to keep hacking on it to try to improve further the speed if >I can. > >Cheers, >Brandon Invergo > Thanks for your work. I'll try st with your patch later this week. With regards, Hadrian Węgrzynowski.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, 7 Mar 2012 00:31:12 +0100 Swiatoslaw Gal wrote: >-- From Matthew Carter 23-01-2012 at 22:01 -- >> You could always run fullscreen apps/games on a separate X display >> using: >> >> xinit $(which gameName) -- :8 >> >> -Matt > >Can one use such a clean solution with a second display? >E.g. an external monitor attached to a laptop? > >s. > `man xorg.conf` or http://linux.die.net/man/5/xorg.conf - section ServerLayout. xinit $(which gameName -- :8 -layout "Your Layout Name"
Re: [dev] smessage
Dnia 2012-02-23, o godz. 18:45:08 Florian Limberger napisał(a): > > An operation Mode without any Buttons where the Window closes > > itselfs after x seconds would be also great I think. Than somebody > > could use smessage also for displaying popup-infos whithin a > > desktop environment for example. > > Thats a nice idea, I think it would be great with the (not yet > implemented) function to force geometry. Closing after x seconds can be made within a simple shell script. So I think you can omit that part of this feature. Maybe only provide script itself as example.
Re: [dev] Wayland
On Wed, 15 Feb 2012 15:28:28 +0100 Eckehard Berns wrote: >I might be wrong, but my biggest fear is that using Wayland means that >I'm getting the current desktop paradigm shoved down my throat. If I >understand this correctly something like dwm would be implemented in >the compositor (for the window placement) and all clients at the same >time (window decorations--or the lack thereof--are part of each >client). It's not a simple program on the side any more. > >My guess is that the Wayland protocol will get bloated pretty quickly >after the first release, since everyone will want their part of X back. >And if it's not part of Wayland there will be more additional standards >on freedektop.org. Heck, the article mentions that currently Wayland >has problems getting popup windows to work because Wayland doesn't >support window positioning by the client! So they're already in the >process of adding standards on top of Wayland. > >Again, I am nowhere near well enough informed, so my statements might >be FUD. > How I understand it is that window decorations are part of compositor's job. If they will leave window positioning unimplemented that can lead to few things. It could be just good for dwm case - windows are positioned as we see fit. Making tray icons would be very simple (not that they are needed). In a way every app could be in tray, like mplayer window (not usefull example). Compositor then would only need a way to tell which windows to put in tray. So how? Extend Wayland? Use dbus? I doubt that they will go with some simpler way. Brain dead extensions can go to dbus leaving Wayland quite clean, but some apps broken. Few things that I would like to know: 1. Will embedding be supported? Could we implement tabbed in Wayland or would it be compositor's (future dwm's) job? Or maybe it would lead to external protocol for embedding? 2. Is there suckless rendering library? :) There was once thread about that in hypothetical Wayland dwm or suckless widget toolkit discussions. 3. Input handling would come from evdev - using kernel interfaces? Will it be filtred by compositor to handle i.e. wm keybindings? It could be good exercise to make static Weston and all other things to check our case. Maybe it will be simpler than with X...
Re: [dev] interested in issue tracker dev
On Wed, 8 Feb 2012 20:15:52 +0100 Anselm R Garbe wrote: >Btw. I would like you to use C and rc, not C and bash or something >similar. There were once discussion about "blessed" rc version, but AFAIR there were no simple conclusion. What version of rc is good enough? What I remember: Byron's version is cursed and p9p version is too big. So which one is good? I don't intend to make another thread out of this, but I would really appreciate simple answer. IMHO sh is acceptable also, but only for simplistic version.
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
Dnia 2012-01-22, o godz. 18:30:03 Anselm R Garbe napisał(a): > Ok, so the error handler trick doesn't work as it exceeds some x > server threshold and then raises an XIO fatal error. > > I will investigate this issue further, but will need a more current X > server first ;) > > Cheers, > Anselm > I will repeat my self. Read this first: http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Thu, 19 Jan 2012 20:53:22 +0100 ilf wrote: >It's reported, that X.Org 1.10.99.902 introduced the possibility to >kill the top X.org window via keybinding Ctrl+Alt+Multiply. I don't >have a current X.Org on this box, but it reportedly works for slock >0.9: > >http://seclists.org/oss-sec/2012/q1/191 >http://gu1.aeroxteam.fr/2012/01/19/bypass-screensaver-locker-program-xorg-111-and-up/ > http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html It's just the way X is.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, 11 Jan 2012 12:35:09 +0500 ∞ wrote: >On 1/11/12, Jakub Lach wrote: >> http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/074856.html >> >> And nothing. >> > > >but, in openbox SDL-apps work fine. need patch for dwm or SDL? > AFAIK openbox is reparenting wm. The problem is that SDL assumes that all wms are reparenting. Which is not true in case of dwm.
Re: [dev] what's your opinion on Go
On Tue, 13 Dec 2011 02:58:31 +0100 Arian Kuschki wrote: >Hi all, > >I would like to learn a new programming language. I do not know C. As >I remember positive reactions on this list when Go came out, I would >like to know if people still think it might be a 'better C'. One thing >I like about Go is that is seems more suitable for server/web stuff, >which is where I 'earn my bread' (working in Java and Javascript >mainly, also Python) . But is it also good for building stuff like >dmenu, dwm, cli tools in general etc? Or is C still king here? > >Cheers, >Arian > C is the king and Go is the prince. Go needs to be more stable/mature, then it will be the king. Hadrian.
Re: [dev] Re: dmenu's lsx binary naming conflicts with lrzsz!
On Mon, 28 Nov 2011 15:43:55 +0100 Christian Neukirchen wrote: >Connor Lane Smith writes: > >> On 28 November 2011 13:35, Christian Neukirchen >> wrote: >>> Any reason we don't replace lsx with this? >>> >>> find -L . -maxdepth 1 -type f -perm -111 >> >> POSIX compatibility. > >All supported except for -maxdepth, but you can use: > >find -L . -type d \! -name . -prune -o -type f -perm -111 -print > It's so convenient. Cheers. I always wonder why such boring subjects get so much more attention than, e.g., Apollo DM topic. It is sad. Yeah, now I'm no better.
Re: [dev] wmii + ruby 1.9.3 = no power woes!
On Mon, 7 Nov 2011 22:28:59 -0800 "Suraj N. Kurapati" wrote: >On Thu 03 Nov 2011 09:57:19 AM PDT, Kurt H Maier wrote: >> There is nothing "suckless" about any aspect of modern wmii > >I thought Suckless folks were enthusiastic about Plan9 technologies; >has this changed? If so, why? > >And how is "modern" wmii different from its, let's say, "pre-modern" >phase? From my view, it still uses the Plan9 protocol and the Plan9 >approach of exposing a virtual filesystem for operation by the user. > >Thanks for your consideration. > Window management in X is quite simple and limited task. We could expose a virtual file system for operation by the user if we would build Window System - X replacement. Such system could possibly gain something by a virtual file system. As for managing windows in X we have now for quite a time something far more superior - dwm. Now you can just work and window manager will manage your windows - that's modern part. Conclusion: wmii - manual window management (is it still management then if it's manual? - more like manual window placement): 30k SLOC + Nk SLOC configuration dwm - dynamic window management: <2k SLOC Any questions?
Re: [dev] PARENT_XID environment variable.
Dnia 2011-11-05, o godz. 18:40:58 Jeremy Jackins napisał(a): > > I would like to add support for surf, zathura and others I use > > daily. > > I already use it with surf, and I didn't have to add any support. > Are you using PARENT_XID environment variable enabled surf? That was the point of my mail.
[dev] PARENT_XID environment variable.
Hi. I hacked tabbed, st and sxiv [1] (and surf, but I couldn't compile it with recent webkit) for support of PARENT_XID environment variable. Tabbed set such variable with its XID. St and sxiv embed in window identified by PARENT_XID if present. This way I can easily browse images "within" terminal "window". Example: Firstly: $ tabbed st Then st in tabbed: $ sxiv example.png Now sxiv is in front. After sxiv is closed we return to st. Two more things. outwin script: #!/bin/sh unset -v PARENT_XID exec $@ subsp - substitute parent (based on sbase nohup command) usage: subsp command nohup command and kill -sighup parent_process Example; st in tabbed: $ subsp sxiv example.png Few things I consider to add to tabbed: hide bar, exit with last client. I would like to add support for surf, zathura and others I use daily. Highly experimental, but works. What do you think? Patches and code: http://www.hawski.com/suckless/ [1] sxiv - https://github.com/muennich/sxiv
Re: [dev] [dwm] 2000 SLOC
On Thu, 3 Nov 2011 18:14:12 +1100 Alex Hutton wrote: >It has occured to me that web-servers should be sending the content in >json format, with the first page load on the site loading a html page >with the json handler in the head. Then if you didn't like the UI >provided by the site you could replace it with your own by using your >own JS and handling the json in your own way. What's the difference between replacing UI in json using your own JS and replacing UI in HTML/CSS using your own JS? That's not the point. We would need something more like Markdown web or gopher... We want content! Presentation could be only client's issue. If somebody likes Apple look then every site could look like one. If one likes plain text look then every site could look like one. But that's not going to happen if we are facing now Web 2.0 Apps Cloud Ultra Fancy... That's 3rd or 4th different topic in this thread.
Re: [dev] How to monitor battery status
On Mon, 20 Jun 2011 11:27:10 +0200 pancake wrote: >On 06/20/11 10:24, Hadrian Węgrzynowski wrote: >> It's maybe not the best way, but I written small utility that uses >> Linux /proc and /sys to take stats. Original source outputs cpu >> usage, cpu freq, cpu temp, mem usage, battery status and gpu temp >> for my thinkpad. >> https://gitorious.org/stater >> To configure it you must change source ;) You can remove wmfs >> formatters. >> I am not proficient in C and Makefile could be better and don't know >> is it suckless enough. >> >this is thinkpad specific. > This is not true. As I said: >> To configure it you must change source ;) You can remove wmfs >> formatters. But of course it needs few more changes than simply changing paths. I use modified version of this on old Athlon XP 2600+ machine and my Pentium Dual Core desktop. You can rip off all but battery status checks and set proper paths. Probably battery status will not need any changes on newer kernels with ACPI_BATTERY, ACPI_SYSFS_POWER and SYSFS (/sys/class/power_supply/BAT0/).
Re: [dev] How to monitor battery status
On Sun, 19 Jun 2011 22:51:46 +0200 Bartosz Nitkiewicz wrote: >Hello, >I'm looking for a best way to monitor battery status in dwm. Any hints? > It's maybe not the best way, but I written small utility that uses Linux /proc and /sys to take stats. Original source outputs cpu usage, cpu freq, cpu temp, mem usage, battery status and gpu temp for my thinkpad. https://gitorious.org/stater To configure it you must change source ;) You can remove wmfs formatters. I am not proficient in C and Makefile could be better and don't know is it suckless enough.
Re: [dev] 2surf, an experiment in tiled browsing
On Sun, 12 Jun 2011 00:38:14 + Bjartur Thorlacius wrote: >On 6/11/11, Peter John Hartman wrote: >> Why not just utilize dwm's tile mode and have each link open in a new >> window? >Presumably so you don't have to close a window after every article you >examine, and resize the search results window. If you're going to >resize the parent window every time before you use it, you could just >as well hide it. >A two-pane setup however mandates the common workflow of skimming the >results, selecting an entry for examination, examining the linked >article, and then either reading article or returning to the results >page for continued skimming. Opening a new window for every activated >link would allow for the alternative workflow of continuous skimming >and then reading articles one after another. >But resizing a pager's window will > It could be implemented as a mode of window manager. - on new client hide and close current master - if master client is closed do not move other windows (master area remain blank) - new client becomes new master Limitation: programs with exit dialogs, but dialogs can be displayed anyway.
Re: [dev] TermKit
Sometimes I would like to display some graphics inside terminal window. We could draw directly in terminal's window or place graphics inline with text. I would prefer second method. One of the key features of text terminals is monospaced font - that makes everything easier to align and easier to code. As I said I would like to display some graphics, but I don't want to give up on grid aligned display. I would prefer to display graphics within text. Applications of this approach: - list graphical files with thumbnails - display images from remote host - display images from mail attachments But for this to make sense program in many cases needs to know width and height of image in terminal characters. Implementation? Maybe whole image in one chunk: escape sequence, width, height, binary image data. Or maybe many chunks in size of character: escape sequence and binary data. Aspect ratio would be the most important factor, besides that terminal could scale chunks. I hope that you can understand me. ;) On Fri, 20 May 2011 13:26:56 +0100 Connor Lane Smith wrote: >Hey, > >On 20 May 2011 12:51, David Tweed wrote: >> Certainly the general implementation, the language and the >> architecture do seem nasty. OTOH, it always depresses me that it's >> kind of taken as a virtue that the interactive shell and the terminal >> are know almost nothing about each other > >fwiw, I agree. TermKit appears to be a very glossy turd, but there are >certainly outstanding issues in our terminals, which is why in Plan 9 >they tried to fix them by pairing a plaintext-only Rio term with >graphical windows which actually replace the spawning term. It's not >perfect, but the plaintext / graphics dichotomy does make things >simpler in some ways. > >I think the way to solve this problem is not to add structure to pipes >(which tend to be simple to use *because* they have no real >structure), but to allow commands to draw directly to the terminal if >they wanted. So the standard input / output piping system would remain >unchanged, and all commands -- except those which rely on unhygienic >escape codes, like curses -- would work just like normal. > >However, if the command would like it could communicate directly to >the term and say "show this diagram", or whatever. The term would >basically be an ever-downward-scrolling canvas, which shows mostly >text but may occasionally display simple graphics too. It would need >some experimentation to find out what the best system would be, but >ultimately it's just the Plan 9 approach except the drawn information >is printed onto the term itself, and thus scrolls with it, rather than >replacing the term entirely. > >This doesn't inherently solve every problem you mentioned, David, but >it would probably be a good first step toward an innovative new >terminal, and would be less vain than TermKit's approach. > >Thanks, >cls >
Re: [dev] MODKEY
Dnia , o godz. KIMURA Masaru napisał(a): > Hi, > > Usually I use wmii on gentoo/ppc. > Recently I was trying to set up Cygwin/X via XDMCP and I noticed that > Mod1 and Mod4 were trapped by Windows. > > What do you think about MODKEY? > Hi. Have you tried -keyhook option?
