Re: How to disable keyboard+mouse input in FVWM?
On 12 September 2014 19:22, wrote: > Still didn't found a way to disable the mouse and keyboard. > > Any hints please? I asked you before what you meant by this, and suggested: Style * NeverFocus Is that not what you're after? It's a pretty odd request. Are you trying to build some kind of kiosk? I've written about such things in the past. -- Thomas Adam
Re: How to disable the mouse cursor in FVWM?
On 12 September 2014 19:18, wrote: > Hello, > > we are using OpenBSD 5.5 with FVWM. > > How can we disable the mouse cursor? > > So we shouldn't see the mouse cursor if we push the mouse a little. > > Is the solution somewhere here? : Not via FVWM directly. You might be able to use unclutter to always hide the pointer though. -- Thomas Adam
Re: How to disable keyboard+mouse input in FVWM?
On 1 September 2014 11:53, wrote: > Besides gluing the USB holes on a PC, how could I disable the keyboard > and mouse input for a logged in user on a OpenBSD 5.5 install with > FVWM? Style * NeverFocus -- Thomas Adam
Re: libmessage (New crazy sh*t)
On 6 July 2014 14:09, Gustav Fransson Nyvell wrote: > This imsg looks pretty much like what I've done, however, libmessage does > not require any bounds checking whatsoever. It's way easier to use. I'm I think you meant to say "does not require any error checking". ;) Don't get me wrong, I don't wish to sound discouraging, but this sort of thing is just an academic exercise at this point. Just use imsg. I see absolutely no benefit to what you're doing, and this whole backend thing with sqlite seem proposterous. Good luck, just don't let others use this. Ever. -- Thomas Adam
Re: libmessage (New crazy sh*t)
On 6 July 2014 13:54, Gustav Fransson Nyvell wrote: > I heard about the iPhone? Thanks, I'll look it up. //Gustav No, not Apple, for goodness sake, man! See this: http://www.openbsd.org/cgi-bin/man.cgi?query=msgbuf_drain -- Thomas Adam
Re: libmessage (New crazy sh*t)
On 6 July 2014 02:20, Gustav Fransson Nyvell wrote: > I made this thing because I wanted or need a way to message between > processes that know nothing about each other, using a central name. > Without requiring any network. So, some basic message passing, across > the OS. It's implemented using sqlite3 which in my case is not good, > because I originally wanted to track fopen/open, and I think there will > be infinite recursion if any of my new functions are used in that > context. So, I'm thinking about another backend for it. You didn't attach any code, thankfully. Have you ever read about imsg? This sounds exactly like what you want, rather than using this sqlite-based thing. -- Thomas Adam
Re: A small package browser
On 19 March 2014 01:56, marst wrote: > Really, nothing out of the ordinary... > > Been working lately on a simple OpenBSD package browser. No extensive > graphics, works from the terminal with navigation similar to vim. I do this > for fun. I find it convenient for exploring existing packages. > > Small description and screenshot available here. > http://mariostg.blogspot.ca/2014/03/openbsd-sqlport-browser.html Interesting. There's also pkg_mgr: http://dawn.rhaalovely.net/pkg_mgr/ -- Thomas Adam
Re: OpenBSD on T61/T500
On 23 February 2014 19:27, Dennis den Brok wrote: > Hello misc@, > > I am considering getting a ThinkPad T61 or T500 to run OpenBSD on. > My main concern is the noise level: I'd prefer the fan not to run > at all during text editing and web browsing. Can anyone comment > on that? Are there other caveats? Well, apmd should help here. I can't comment on the T500, but the T61 has a built-in NVIDIA graphics card; something which will cause annoyances for you with OpenBSD. It might work OK with the nouveau driver, I couldn't say. I've got an X201 myself, and that works flawlessly, but then that had the correct amount of support hardware for me before I bough it. -- Thomas Adam
Re: [cwm] menusearch/exec bind problem
On 10 January 2014 22:35, Jiri B wrote: > Hi, > > I have following configuration: > > $ egrep "search|exec" .cwmrc > bind 4-p menusearch > bind C-/ exec > > But even after restart, C-/ shows me menusearch (application) > search, instead of search for command. It's "slash", not "/" in X11 parlance. > PS: Does exist any specific list or IRC channel for cwm? We have ##cwm on Freenode. -- Thomas Adam
Re: fvwm in base [was: "X -configure" segmentation fault]
Marc, On 15 September 2013 21:34, Marc Espie wrote: > On Sun, Sep 15, 2013 at 08:12:53PM +0100, Thomas Adam wrote: >> Hi, >> >> On 15 September 2013 11:48, Jérémie Courrèges-Anglas wrote: >> > James Griffin writes: >> > >> >> * Thomas Adam [2013-09-12 10:17:56 +0100]: >> >> >> >>> On 12 September 2013 06:10, Carson Chittom wrote: >> >>> > Zoran Kolic writes: >> >>> > >> >>> >> In fact, fvwm is in base part. >> >>> > >> >>> > A while ago, there was a message to misc from the fvwm developer about >> >>> > relicensing fvwm to allow a more recent version into base. I wonder if >> >>> > there is any status update? >> >>> >> >>> That is I. Unfortunately, FVWM cannot be relicensed. >> >>> >> >>> -- Thomas Adam >> >> >> >> If it can't be relicensed so an up-to-date version can be included in >> >> the base distribution then is there much point in it being there at all? >> >> People can simply use the package/port to install a supported version >> >> and the base distribution can simply have cwm as its main wm. >> > >> > Lots of people use the base fvwm. Which works fine for them, even if >> > older. Also fvwm is easier to work than cwm when you don't know either. >> >> I agree. The fact that there's a newer version of FVWM in ports is >> fine; FVWM in base, despite being older might be a minor nuisance, but >> not insurmountable. > > One thing we can do is re-do some of the useful code. Unfortunately, whilst this might work for very simple things, you're on to something of a lost cause in the grander scheme of things (read: you might as well just write your own window manager.) I'd dearly love to be able to relicence FVWM, but that requires something I cannot do for a twenty year project. It's a real shame, but there's code added there from all sorts of proprietary companies over the years, and contacting them in nigh impossible. > I've been playing a bit with the newer one. One thing I really would like > is for chromium (video) and fvwm to play nice with each other, namely an > implementation of the stuff that makes it possible to go fullscreen and back. > > Point me in the right direction, and I will look at rewriting this under > a reasonable licence... This is where it'll go south. You need EWMH support for this, and you can't just pick-and-choose the best bits and shoe-horn it in to that FVWM version at all easily. The undertaking would be quite big. -- Thomas Adam
Re: fvwm in base [was: "X -configure" segmentation fault]
Hi, On 15 September 2013 11:48, Jérémie Courrèges-Anglas wrote: > James Griffin writes: > >> * Thomas Adam [2013-09-12 10:17:56 +0100]: >> >>> On 12 September 2013 06:10, Carson Chittom wrote: >>> > Zoran Kolic writes: >>> > >>> >> In fact, fvwm is in base part. >>> > >>> > A while ago, there was a message to misc from the fvwm developer about >>> > relicensing fvwm to allow a more recent version into base. I wonder if >>> > there is any status update? >>> >>> That is I. Unfortunately, FVWM cannot be relicensed. >>> >>> -- Thomas Adam >> >> If it can't be relicensed so an up-to-date version can be included in >> the base distribution then is there much point in it being there at all? >> People can simply use the package/port to install a supported version >> and the base distribution can simply have cwm as its main wm. > > Lots of people use the base fvwm. Which works fine for them, even if > older. Also fvwm is easier to work than cwm when you don't know either. I agree. The fact that there's a newer version of FVWM in ports is fine; FVWM in base, despite being older might be a minor nuisance, but not insurmountable. -- Thomas Adam
Re: fvwm in base [was: "X -configure" segmentation fault]
On 12 September 2013 06:10, Carson Chittom wrote: > Zoran Kolic writes: > >> In fact, fvwm is in base part. > > A while ago, there was a message to misc from the fvwm developer about > relicensing fvwm to allow a more recent version into base. I wonder if > there is any status update? That is I. Unfortunately, FVWM cannot be relicensed. -- Thomas Adam
Re: Seeking GUI refuge
On 25 May 2013 18:29, Marc Espie wrote: > There are transient windows annotations that fvwm completely disregards. Can you give me examples of applications which this is lacking in? I bet they behave fine in FVWM 2.6.5. > The other thing it doesn't really support is multiple screen support > and xrandr. Well, FVWM outright doesn't support XRandR, no (go and see the archives of fvwm-workers as to why---mostly posts from myself will help there), but it does support Xinerama. I think it's much more worthwhile at this point for me to go away and check the history of the project in more detail to understand why the licensing was switched away, and what I can do to put it back again, if anything. I appreciate the version in OpenBSD proper is ancient, but it's somewhat short-sighted to think it's a worthwhile endeavour for anyone to somehow back-port features from the current version of FVWM to the version in OpenBSD proper---the internals are completely different. So I'll see what I can do about re-licensing FVWM. -- Thomas Adam
Re: Seeking GUI refuge
On 25 May 2013 16:53, Marc Espie wrote: > On Sat, May 25, 2013 at 10:19:56AM +, z...@sdf.org wrote: >> On Fri, May 24, 2013 at 06:48:05PM -0400, Patrick Mc(avery wrote: >> > I tried to load Fluxbox and was disappointed with it. It had several >> > menubuttons for application that were not yet installed. >> >> There is more than just Fluxbox out there. That's UNIX world, it >> is up to you and you have plenty of choices. >> >> Bloatware like Gnome, XFCE, KDE and other crap is available through ports. >> >> Minimalistic versions like fvwm, cwm are waiting to be configured to meet >> your special needs. And in fact, if you cut through the clutter of options >> and manpages, you might be much more satisfied than using some windows >> version where you just can tick an option on or off. > > We're still waiting for someone with time on his hands to take over fvwm > development. I can help there, being the only upstream developer for FVWM for now. Specifically, what is it which is lacking from your point of view which needs amending? A statement of "very little support for modern X" doesn't make a lot of sense to me. What's the _behaviour_ from FVWM which you perceive as lacking? > Specifically, the upstream development team DID switch to GPL, so we're > stranded with the one in xenocara, with very very little support for modern > X, which is a shame... Hmm. I too find that somewhat irritating also. -- Thomas Adam
Re: tmux window resizing
On 3 April 2013 17:14, Ted Unangst wrote: > > short version: how do i make tmux stop resizing the window? setw -g aggressive-resize off Does this for me. Note that it's not set by default. -- Thomas Adam
Re: tmux separate pane characters
On 7 December 2012 17:19, Daniel Bolgheroni wrote: > Hi misc@, > > I have an issue with some fonts when using tmux, as they don't display > the separate characters between panes. > > Are there any -a option as in mc or 'ascii_chars=' as in mutt? No -- the fallback is to use the ASCII equivalents when ACS cannot be used. -- Thomas Adam
Re: all freezes when I move windows in twm
On 18 April 2012 19:04, Christian Weisgerber wrote: > Alexei Malinin wrote: > >> At a time when I listen to music on the xmms >> and simultaneously begin to move any X window, >> the sound stops. The sound resumes after finishing >> of moving of the window . > > Yes. B For some window operations like moving or resizing windows, > window managers (at least twm, fvwm, mwm) cause all window updates > to stop, in turn causing applications to stop. B This is very > noticeable with xterm and programs running in xterm. B As you have > noticed, xmms also stops. Window managers like twm and FVWM which hail from the days when moving windows which were still mapped fully caused problems, would often draw a window outline instead to represent the window. During the move/resize operation (leading to a huge round-trip of ConfigureNotify events) these could be effectively ignored until the actual placement of the window had been made, and then the window would redraw correctly. During the entire time the window is being moved though, the XServer is grabbed. This has the effect that all applications "stop" -- and for most applications -- XMMS included -- this often means they're interrupted since the events destined for the windows are queued pending the eventual XServer ungrab. To this end, FVWM solves this with OpaqueMove, as does TWM. So I would say to the OP that he looks at the following TWM options: NoGrabServer OpaqueMove -- Thomas Adam
Re: Failed to setup fvwm for antialiased Xft fonts
Hi, On 8 December 2011 16:32, Neoklis Kyriazis wrote: > Hi all > > I have been trying in vain to setup fvwm for anti-aliased fonts > in > obsd 5.0. I tried the instructions in man of fvwm and some > tips on google, but > with no result. fvwm reports that it can't > get the specified fonts. I made > sure I used fonts as listed by > fc-list and tried them in xterm's config, which > worked, also on > my Arch Linux installation. > > Is it possible to have > anti-aliased fonts in OpenBSD's fvwm? > If so, any hints please? No -- OpenBSD's version of FVWM as included in base is ancient. Get the one from ports which will have XFT support. -- Thomas Adam
Re: Webmin with OpenBSD
On 8 October 2011 21:30, Javier Bassi wrote: > If the above does not work, check if edquota and setquota are > functioning properly. If they do, forward this to > webadmin-de...@lists.sourceforge.net and cc kevin lo, or make a bug > report at github. OpenBSD support in Webmin still buggy. Not to mention Webmin is a huge security risk, has been for a long time and a lot of Linux distros for example have long-since dropped support for it. Why would anyone want to even try and use Webmin with anything? Just don't use it. Seriously. -- Thomas Adam
Re: cwm autogroup confusion
On 8 September 2011 10:39, Okan Demirmen wrote: > confusing that the atom is named WM_NAME while WM_CLASS includes app > name and class, which are different properties. No, WM_CLASS includes the *resource* name, and the class, which has nothing to do with WM_NAME. Yes, WM_CLASS should be used, because this property cannot change once the window has left the WithDrawn state when it's mapped. Please do not confuse the resource property of WM_CLASS with the window's WM_NAME. -- Thomas Adam