Re: [dev] I made a bluetooth-control-thing
On Thu, 16 Jun 2022 19:39:14 +0100
Ethan Marshall wrote:
> On 16/06/22 04:33pm, David Demelier wrote:
> >
> > Hi,
> >
> > There is something wrong with the makefile because each time I type
> > make it keeps rebuilding everything.
>
> From having built it myself, I can confirm that change detection seems
> to be broken for libsl/drw.c and all files in the libwdgt and sdb_bt.
> Everything else seems to be working correctly.
I just had a look into this. I have no simple idea to make it better.
The Makefile runs make commands for every sub-project, thus the main
Makefile does not have to know anything about the sub-projects
Makefiles. Change detection "works" in the way that nothing is actually
build, but does not work because all sub-makes are executed.
>
> > $ lbm
> > X Error of failed request: BadWindow (invalid Window parameter)
> > Major opcode of failed request: 15 (X_QueryTree)
> > Resource id in failed request: 0x0
> > Serial number of failed request: 12
> > Current serial number in output stream: 12
>
> When I tried to auto-launch using .xprofile (which is ran before the
> windowmanager but after xorg starts), I got the exact same error.
> However, when I changed this in order to launch after the window
> manager which runs the system tray, this error does not appear and
> everything works as expected. Could this be something to do with
> incorrectly waiting for a system tray to be available? Do you
> definitely have a window manager which supports a system tray running?
>
Rats. I thought i had that, but apparently i don't :)
I have a look at it as soon as i have time (probably a week or so). The
whole systray thing is pretty tough, i seem to be unable to find good
documentation ("good" as in good enough for me).
pgp1yJbwI6Sic.pgp
Description: OpenPGP digital signature
[dev] I made a bluetooth-control-thing
I was always a bit annoyed by the lack of a simple, gui-based bluetooth control thing. Like blueman, but not in a scripting language. And maybe with somewhat simpler interface. Thus i did this: https://git.weitnahbei.de/nullmark/little_blue_man Its written in C, uses drw and dbus and it works. At least for me. It lacks many features and proper testing. And i got somewhat carried away and dabbled with ideas of starting my own toolkit. Turned out, such a thing is quite big a thing, thus there is no toolkit, but the code is somewhat more complicated than it has to. Anyway, i would like to hear some opinions :) Sidenote and a warning: i am not a good c programmer. I just like to use it :) pgpbPIJNgpuJ3.pgp Description: OpenPGP digital signature
Re: [dev] [announce] wjt-0.1 - slider widget
On 13.12.2016 02:42, Ian Remmler wrote: > I hope others will find it useful. I like the idea. And i instantly wished for it be able to: - provide multiple sliders in one instance and returning multiple values (eg mixer) - just display the current slide value, without interactivity and vanish after some time (status displays and such). In this case it should, when called again, be able to either: - change value of the currently displayed slide (when told which slide to overwrite) - display multiple instances Well, probably i should implement that instead of just talking about it. But i have neither* time nor any idea how to do propper ipc in such a case. What remindes me: I think we need a suckless message bus ;) * And im lazy, which really does not help :) signature.asc Description: OpenPGP digital signature
Re: [dev] [farbfeld] announce
On 18.11.2015 11:16, Stefan Mark wrote: > On 17.11.2015 18:43, FRIGN wrote: >> On Tue, 17 Nov 2015 18:34:06 +0100 >> Stefan Mark <m...@unserver.de> wrote: >> [stuff] As a side note, i dont mean to press the issue or annoy you. It is just an idea. Just say if you dont want to discuss it any further :) signature.asc Description: OpenPGP digital signature
Re: [dev] [farbfeld] announce
On 18.11.2015 11:49, FRIGN wrote: > On Wed, 18 Nov 2015 11:16:56 +0100 > Stefan Mark <m...@unserver.de> wrote: > >> What i meant, instead of having RGBA and only RGBA, it could have a flag >> that says either which color model is used, (like rgb, rgba, lab, >> monochrome, ...) or define how many color channels the image has, either >> named or by giving the channels wavelength. > > you don't need a specialized format for RGB-data. If the alpha-channel > is always 65535 (maximum), the compression will take care of it. > I already went down the LAB-path. It may be the superior colorspace, but > nobody uses it anyway. and it's painful to work with. > monochrome data is a special-case of paletted images, and farbfeld in > its current state is _superior_ in handling this. > If you only have black, green and pink pixels in your image, the > compression algorithm will handle this perfectly. same applies to > greyscale images. > >> That would allow for example scientific images to be stored (eg, r,g,b >> channels as well as a few infrared ranges and a bit of uv, maybe imaging >> radar, ...), or arbitrary image-like data (eg pressure, temperature, >> tensile stress, ...), or special colors for printing (eg cmyk and >> metallic color, glow-in-the-dark-color, transparent coating, ...). > > The point you are missing here is that RGB is not a color model based on > the true physical perception of color. > LAB gets closer, but you can't really "easily" mix LAB color-data with > IR-data, because we can't see infrared light, and the three axes of the > LAB-color-space only take in regard those color-ranges perceived by our > eyes. I guess you could encode Infrared data, given the axes are > unlimited, but how does this help? > It all boils down to assigning infrared-data to color-data we can > perceive, and there's no reason not just to use Farbfeld RGBA for that. > For instance, when you have an IR-camera from your military drone, you > just map it smartly onto a greyscale 16-Bit range and be done with it. > I think i see. Sure, for visual representation, 16 bit wide rgba is probably more than enough. What i proposed was to expand the format to be useful beyond representing visual images but represent arbitrary image-like data. Probably completely out of the projects focus, sorry, got carried away :) signature.asc Description: OpenPGP digital signature
Re: [dev] [farbfeld] announce
On 18.11.2015 12:52, FRIGN wrote: > On Wed, 18 Nov 2015 12:36:51 +0100 > Stefan Mark <m...@unserver.de> wrote: > > Hey Stefan, > >> I think i see. Sure, for visual representation, 16 bit wide rgba is >> probably more than enough. > > I thought long about how much bits I want per color-channel. One format > cannot solve all problems as not one program can do all tasks (even Emacs > may be a great operating system, but it lacks a good text editor). You can easily write a x86 emulator in lisp and use it to run ed. There, standard editor, no problem ;) signature.asc Description: OpenPGP digital signature
Re: [dev] [farbfeld] announce
On 17.11.2015 18:43, FRIGN wrote: > On Tue, 17 Nov 2015 18:34:06 +0100 > Stefan Mark <m...@unserver.de> wrote: > > Hey Stefan, > >> I know, its all about simplicity, but with only a marginally higher >> complexity an arbitrary number of channels and color spaces could be >> supported. Something like this: >> A type field >> ++---+ >> | 1 | Type of channels: 0 predefined, 1 wavelength, 2 names | >> ++---+ >> and, depending on the type: >> >> type 0 >> ++---+ >> | 8 | For example RGB, RGBA, CMYK, LAB, ... | >> ++---+ >> >> type 1 (Multispektral Images) >> ++---+ >> | 2 | Number of Channels| >> ++---+ >> | [8]| List of lower/higher wavelength of channel (2 floats) | >> ++---+ >> >> type 2 (Arbitrary image-like data) >> ++---+ >> | 2 | Number of Channels| >> ++---+ >> | [32] | List of channel labels (32 byte long strings) | >> ++---+ > > I read your mail at least 10 times now, but I've still got no clue > what the hell you are talking about. What i meant, instead of having RGBA and only RGBA, it could have a flag that says either which color model is used, (like rgb, rgba, lab, monochrome, ...) or define how many color channels the image has, either named or by giving the channels wavelength. That would allow for example scientific images to be stored (eg, r,g,b channels as well as a few infrared ranges and a bit of uv, maybe imaging radar, ...), or arbitrary image-like data (eg pressure, temperature, tensile stress, ...), or special colors for printing (eg cmyk and metallic color, glow-in-the-dark-color, transparent coating, ...). For common image purposes, the format would be only a very small bit more complex, although it would be much more versatile. Providing a method to define the amount of dimension used would be nice too. > If we go down this path, we probably would end up with the TIFF format > in finite time. I dont think so. The changes compared to the original format are pretty small. signature.asc Description: OpenPGP digital signature
Re: [dev] [farbfeld] announce
On 10.11.2015 22:37, FRIGN wrote: > ++---+ > | [] | 4*16-Bit BE unsigned integers [RGBA] / pixel, row-aligned | > ++---+ There are lots of different color spaces like CMYK or LAB. And scientific applications often have an arbitrary number of weird channels. I know, its all about simplicity, but with only a marginally higher complexity an arbitrary number of channels and color spaces could be supported. Something like this: A type field ++---+ | 1 | Type of channels: 0 predefined, 1 wavelength, 2 names | ++---+ and, depending on the type: type 0 ++---+ | 8 | For example RGB, RGBA, CMYK, LAB, ... | ++---+ type 1 (Multispektral Images) ++---+ | 2 | Number of Channels| ++---+ | [8]| List of lower/higher wavelength of channel (2 floats) | ++---+ type 2 (Arbitrary image-like data) ++---+ | 2 | Number of Channels| ++---+ | [32] | List of channel labels (32 byte long strings) | ++---+ signature.asc Description: OpenPGP digital signature
Re: [dev] [sent] 0.1 release
On 12.11.2015 13:20, Markus Teich wrote: > Heyho, > > I am happy to announce the version 0.1 release of sent, a suckless > presentation > tool. That is just Awesome. It was only two days ago that i thought i need just that kind of thing. Perfekt timing :D thanks! signature.asc Description: OpenPGP digital signature
Re: [dev] Plain text editor that sucks less - an alternative to VIM?
On 02.07.2014 15:52, Alexander S. wrote: It's still incredible to me how some people think they're better than others on absolutely no grounds, though. I dont think the problem is that some people think they are better. The problem is that these people think that they KNOW(TM) what is the right way. They cant imagine that different people do things differently, that there are always many ways to do things, and not a single one is the objectively best for everyone. On 02.07.2014 16:15, Dimitris Papastamos wrote: On Wed, Jul 02, 2014 at 05:52:41PM +0400, Alexander S. wrote: It's still incredible to me how some people think they're better than others on absolutely no grounds, though. That's your impression. Ah, well, thanks for making my point :)
Re: [dev] monsterwm - 700 SLOC dwm fork
On 30.12.2011 21:35, Kurt H Maier wrote: I love arch linux's facility for coralling all the nitwits into one self-contained forum. It just sucks when some of the retardation leaks out into the real world. This statement has some nice boomerang Irony.
Re: [dev] dwm 6.0
On 19.12.2011 17:21, Andrew Hills wrote: On Mon, Dec 19, 2011 at 11:10 AM, Thomas Dean 78...@web.de wrote: Of course, now I see it: 0=infinity in this case, i.e. slave effectively becomes master :-) Be careful when creating a power vacuum. Eliminating the remaining authority will lead to anarchy as the slaves all scramble to create a new class of masters. --Andrew Hills Magnificent. Brilliant. Bodacious. Capital. Oberaffentittengeil. You made at least my day, and quite possibly my week :D
Re: [dev] [st] Drawing optimizations
On 21.10.2011 00:00, Aurélien Aptel wrote: Hi, I know st rendering is slow. I'm currently trying out different solutions but I can tell you profiling X calls is no fun. tip now uses a simple dirty flag per line algorithm. Each modified line has the flag set to 1. Only dirty lines are drawn and once it's done their flag is set back to 0. I've noticed a significant speed up. I'll try more ideas in the near future. I dont know if this helps: It seems to depend strongly on the Graphics driver. Using intel or a very old nvidia card (riva128), st is reasonable fast. But when using radeon open source drivers (tested on two different cards), its extremely slow. Other terminals (xterm and rxvt-unicode) are noticeable slower with the radeon driver (strangely, i notice this slow-down only with terminals, everything else runs well), but totally usable, while st drops from a bit annoying slow to virtually unusable.
Re: [dev] st features that'd be nice
On 18.10.2011 18:39, Andrew Hills wrote: On Tue, Oct 18, 2011 at 9:13 AM, Stefan Mark m...@unserver.de wrote: For me, performance is the main issue. Drawing of 'mc' on higher resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on a reasonable fast machine. Drawing 'top' took a bit less, but not much. When doing so, st itself uses nearly none cpu time, but x11 took around 97%. (using st 0.1.1) Strangely enough, at 1400x1050 on a Pentium M laptop running at 1GHz, I find no performance issues running top, with a CPU usage somewhat, but not significantly, higher than xterm's (for both st and X). This is with st tip and 0.1.1. That sure is strange. Even in a small window (around 80x30), mc took about 1s to render for me. Just typing in the last row makes X consuming around 20% (on a 2.6ghz core2). The strange thing is, typing in the first row only needs 6%. This problems seems to be related to the radeon video driver, cause it not happens on my Notebook, which has Intel graphic. I will test it on a nvidia soon.
Re: [dev] st features that'd be nice
On 18.10.2011 13:15, Peter John Hartman wrote: Here's a feature request that should go in first: make st usable. For me, performance is the main issue. Drawing of 'mc' on higher resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on a reasonable fast machine. Drawing 'top' took a bit less, but not much. When doing so, st itself uses nearly none cpu time, but x11 took around 97%. (using st 0.1.1)
Re: [dev] Re: Digest of dev@suckless.org issue 112 (8981-9030)
On 05.07.2011 00:50, a.l.e wrote: hi ... not bad... if i can disable transparency, it may be worth a try! Sure you can. There is a config variable in config.h. Well, not a preprocessor directive, but since it only adds a few lines and does not need any libs, i think thats ok.
Re: [dev] wmii as a prepatched dwm (Was: segfault)
On Sat, 2 Jul 2011 18:12:41 +0200 a.l.e ale.comp...@xox.ch wrote: one first sorrow: the goal of dwm-sprinkles is to add all the available patches... No, definitely not :) i would be happier to some of them... plus a few which i would not use but other think are important. I intend to make some patches optional (eg the bar stuff, it seems that no one except me is using it) somehow, i would feel better if the project would have a more focused goal i could agree with :-) I never had a goal, except putting everything together what i liked. But maybe it is time to set some goals, now that some people are using the thing. What i wanted: - Extending tags - pertag, with multi-monitor capability - perlayout (similar to pertag but for layouts, as seen partially on pertag2) - Tab or taskbar like ability - moving of clients in list - some modes of appending new windows (as first, as last, right of, ...) - appending windows 'tagless' and hidden to a stack list (not achieved yet) - Eye candy - colors and stuff in the bar - systray - transparency - Layouts - more flexible 'normal' layout, partly achieved through ntile, nmaster and bstack, soon to be replaced with flextile - spiral, grid and maybe others - Little helpfull stuff - no goal, just add what seems helpfull, eg. alt-tab like behaviour, maximize, scratchpas, ...) Any suggestions?
Re: [dev] Simple application launcher?
On 30.06.2011 16:35, John Matthewman wrote: It would be handy to have a little launcher sitting at one corner of my screen, waiting for me to click a button to launch one of those predefined applications. I like xmenud, its written in Python, uses XDG Menus and can be put in the systray: http://mad.unserver.de/2010/xmonad/xmenud/
Re: [dev] How to monitor battery status
On 20.06.2011 12:17, Stefan Mark wrote: Just two Days ago i found a nice and relatively complete one in this Mailinglist. Since then, im tinkering around with it, with the intention to make it more or less a replacement for my old perl project. It has some monitors and libnotify support. If there is interest, i could make a svn. If anyone is interested, here is the svn: https://svn.0mark.unserver.de/dwmbarthingy/
Re: [dev] How to monitor battery status
On 19.06.2011 22:51, Bartosz Nitkiewicz wrote: Hello, I'm looking for a best way to monitor battery status in dwm. Any hints? I use a extensible perl script (https://svn.0mark.unserver.de/dwmd/branches/experimental/). Not perfect, but easy to maintain and extend. The script features Monitors for temp (acpi and lm-sensors), cpu clock, battery, wireless signal strength, mpd and date. It also provied wallpaper changer and autostart. Lacks documentation. But i think think this is a better solution: http://dwm.suckless.org/dwmstatus/
Re: [dev] How to monitor battery status
On 20.06.2011 12:47, Kurt H Maier wrote: On Mon, Jun 20, 2011 at 5:59 AM, ilf i...@zeromail.org wrote: I have done this the /proc/acpi/battery/BAT0/state | shell way for years and found it to be way more resource intense then calling acpi -b. Let's face it, the Shell/Perl/Python/whatever scripting is relatively easy, but very inefficient. I update my status bar every 50 seconds. I sacrifice, for this, approximately thirty seconds of battery life on a battery that lasts on the order of seven hours to a charge. I'm not particularly concerned by this 'inefficiency,' to be honest. On one of my system im really concerned about the ram usage. But mostly its because i dont like to waste resources. It just nags me having a perl script running that uses twice the memory as the window manager just to display some status information. And it adds up. 2 for the status, 6 for a python based notifier, maybe a wallpaper changer or a udev daemon...
Re: [dev] [dwm] devilspie doesn't work
On 05.05.2011 22:04, Al Gest wrote: You know what's great? freedom of choice. You know what sucks? People telling you what you're allowed to do with the software you use. Is this suckmore or suckless? Only sane argument so far. Anyway, go on list, i have enough Popcorn for the show :P greets stefan mark
Re: [dev] [dwm] devilspie doesn't work
On 04.05.2011 23:00, Rob wrote: And apply the patch. It might not apply cleanly since I diff'd from my heavily patched dwm, so you'll have to do some shuftying. There are also two other transparency patches available at the dwm site: http://dwm.suckless.org/patches/transparency (configurable by rules) and http://dwm.suckless.org/patches/defaulttransparency (manual setting)
Re: [dev] [st] bold as bright (again)
On 01.04.2011 15:06, pancake wrote: Oh.. i was about to push the patch...until I realized the original thread. Yay! ... A Check those pictures: I get a 404 on both, but i tried myself (with my irssi settings the display is correct). The 256colors2.pl is strange, i dont know what the first two for loops are for, the script works fine on both terms when these are commented out (and the output looks the same as in xterm without the comments). You may see some other differences... and the missuse of bright when bold sometimes hurts my eyes... but some programs just are hard to read without it... Yep, i know. Switching by hotkey might be a solution. So, before adding this patch I would prefer some more discussion to make st more usable. and less eye-harmful. Ok, let me know if i could help. Anyway, i think most of the mentioned problems do not affect this patch directly. greets stefan
Re: [dev] [st] bold as bright (again)
On 01.04.2011 15:42, pancake wrote: http://lolcathost.org/b/stcolors.png http://lolcathost.org/b/stcolors2.png Both works for me These work, the directory was missing. Anyway, the irssi display looks good to me. I have the default colors in config.h, and see no difference between xterm and st.
Re: [dev] [st] bold as bright (again)
On 01.04.2011 15:50, Ethan Grammatikidis wrote: On 1 Apr 2011, at 2:06 pm, pancake wrote: You may see some other differences... and the missuse of bright when bold sometimes hurts my eyes... but some programs just are hard to read without it... Why does no-one ever seem to consider just not using programs which are broken this badly, or at least filing serious bug reports on them? It's They are not broken. As far as i understand it, both ways are correct. Early terminals did not have bold fonts, so bold text was done using higher brightness (which actually looked bold on these Eye burning machines).
Re: [dev] [st] bold as bright (again)
On 01.04.2011 16:28, pancake wrote: On 04/01/11 15:51, Stefan Mark wrote: On 01.04.2011 15:42, pancake wrote: http://lolcathost.org/b/stcolors.png http://lolcathost.org/b/stcolors2.png Both works for me These work, the directory was missing. Anyway, the irssi display looks good to me. I have the default colors in config.h, and see no difference between xterm and st. oops. sorry i was using the old config.h with the new config.h i get irssi ok with and without the patch and it looks like xterm. So...can you give me any example/reason why apply this hack? (imho: bold is not bright), and programs missusing this concept should be fixed, and authors notified. for example: http://0mark.unserver.de/filez/htop.png Most things are not that bad (text is not visible), but sometimes annoying or dull looking. I could make more examples later. All other Terminals i know off make bold to boldbright, so most programs are made for this.
Re: [dev] [st] bold as bright (again)
On 01.04.2011 16:40, Stefan Mark wrote: All other Terminals i know off make bold to boldbright, so most programs are made for this. Mostly they are useable without the patch, but look different to other terminals (kind of dull). Some People seem to like that, i do not. Thats why the patch makes the change optional. I agree that in case of htop its a bug, because both ways (st and xterm) are correct (as far as i know), so it should be usable without the patch. I also agree that the bold to bright behavior is ugly, but the bright colors themself are ok for me.
Re: [dev][st] multibyte patch
On 19.11.2010 01:12, Damian Okrasa wrote: #define TNAME st Nice, that worked, thanks!
Re: [dev][st] multibyte patch
On 17.11.2010 14:54, Damian Okrasa wrote: changed FONT and BOLDFONT, more fonts are selected fixed bug in ttyread, does ncurses apps work correctly? The cursor keys did not work in midnight commander (they did last version), and i get a lot error messages like this one: erresc: unknown csi ESC [ ? 9 l
Re: [dev][dwm] Rule to don't manage a window?
On 15.11.2010 11:42, thu...@singularity.fr wrote: Hello! The thing I want to do, is to configure dwm in order it doesn't manage some windows. Infact, the problem is when I launch dwm, when I cycle throught windows, stalonetray can still be selected. And what I want is to have stalonetray pasted in the background, over the status bar. Is there any solution to do such thing? This patch might help: https://bbs.archlinux.org/viewtopic.php?id=102860
Re: [dev] [st] multibyte patch
On 07.11.2010 22:09, Damian Okrasa wrote: LC_CTYPE=en_US.UTF-8 should be set for UTF-8, it has some bugs and sometimes doesn't recognise good UTF-8 string. http://img51.imageshack.us/img51/4591/201011072157261024x768s.png Woah, Great patch! Thanks a lot!
Re: [dev] [OT] Music?
On 09.09.2010 05:07, Jacob Todd wrote: On Wed, Sep 08, 2010 at 07:10:56PM -0400, Kris Maglione wrote: social justice Social justice is just yet another way of saying slavery and theft. Well, on the other hand, it might be that saying such things is just another way of saying 'mine! mine! mine!'... But back to be on topic on the off topic topic, i like quite a lot, from mussorgsky to wizo, from leslie fish to sunn o, from welle:erdball to cultus ferox, and everything between and even just some more. Anyway, i dont think that 'suckless' is a good term to describe music. Who listens to music that only sucks less? Music has to be bodacious at least. ... 'bodacious', what a great word. Never heart it before.
Re: [dev] [st] Bold Text should be bright?
On 03.09.2010 00:41, Aurélien Aptel wrote: If more people want it, I might apply it. But judging from reactions in this thread, I don't think it's going to happen. Hm, ok. Then what about a patches section on the st page, like on the dwm page?
[dev] [st] Bold Text should be bright?
Im not sure if this is right, but most Terminals seem to make bold text
also bright. Some programs, like htop for example, rely on this. As far
as i remember, the first 8 colors should be mapped to the second 8
colors for bold text.
Here is a patch that does this. With it applied, man pages and htop
looks the same in st as in rxvt.
greetings
stefan mark
diff -r 656f8e521f85 st.c
--- a/st.c Thu Sep 02 02:03:53 2010 +0200
+++ b/st.c Thu Sep 02 10:53:11 2010 +0200
@@ -1223,8 +1223,12 @@
if(base.mode ATTR_REVERSE)
xfg = dc.col[base.bg], xbg = dc.col[base.fg];
- else
- xfg = dc.col[base.fg], xbg = dc.col[base.bg];
+ else {
+ if(base.mode ATTR_BOLD BETWEEN(base.fg, 0, 7))
+ xfg = dc.col[base.fg+8], xbg = dc.col[base.bg];
+ else
+ xfg = dc.col[base.fg], xbg = dc.col[base.bg];
+ }
XSetBackground(xw.dis, dc.gc, xbg);
XSetForeground(xw.dis, dc.gc, xfg);
Re: [dev] [st] Bold Text should be bright?
On 02.09.2010 11:48, pancake wrote: I always hated bright fonts. Bold is bold and bright is bright. I dont like it either, but it seems to be some kind of standart. Well, the wikipedia says: 'Bright (increased intensity) or Bold', so both could to be right, and sadly bold might be bright and bright might be bold ;) Some Programs relay on it. Htop for example has bright (or bold) black text on black background. Without making bold also bright, its invisible. Many other look strangely dull. Many people (like me) dont like bold text in terminals, and set the same font for bold as for normal text, which is rather useless without making bold also bright.
Re: [dev] Fullscreen keyboard shortcut in dwm like in wmii
I use this function, it makes a client float and maximize.
void
togglemax(const Arg *arg) {
Client *c;
if(!(c = selmon-sel))
return;
Monitor *m = c-mon;
c-isfloating = !c-isfloating || c-isfixed;
if(c-isfloating)
resize(c, m-wx, m-wy, m-ww - 2 * c-bw, m-wh - 2 *
c-bw, True);
arrange(selmon);
}
Bar and Border remain, but if you change
resize(c, m-wx, m-wy, m-ww - 2 * c-bw, m-wh - 2 *
c-bw, True);
to
resize(c, m-wx, m-wy, m-ww, m-wh, True);
it should do a fullscreen (not tested).
Re: [dev] plumb 1.0
On 14.07.2010 19:28, Mate Nagy wrote: On Wed, Jul 14, 2010 at 07:25:56PM +0200, Uriel wrote: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb well darn, should've expected it from plan9 :) yeah, i'll consider the name change, it's no problem at this point - any suggestions for names? :) For something that tinkers with pipes? Mario, what else? PS: The next release could be named super-mario :D with 8bit greetings stefan
