beta3 mouse shading
I just installed beta3 on one of my machines, and most everything seems rock solid. The only thing that I'm missing is a feature I'd noticed and liked that I first saw in the alpha series (I'm running alpha7 on my other box) -- being able to shade a window using the mouse wheel. Has this feature been removed from the 0.65 series? (i.e., did it accidently creep into the alpha and was later removed for addition in 0.70?) --Matthew
RE: beta3 mouse shading
On Tue, 2002-07-23 at 10:55, Sean 'Shaleh' Perry wrote: On 23-Jul-2002 Matthew Weier O'Phinney wrote: I just installed beta3 on one of my machines, and most everything seems rock solid. The only thing that I'm missing is a feature I'd noticed and liked that I first saw in the alpha series (I'm running alpha7 on my other box) -- being able to shade a window using the mouse wheel. Has this feature been removed from the 0.65 series? (i.e., did it accidently creep into the alpha and was later removed for addition in 0.70?) --Matthew It was never in blackbox. There have been patches but it was not added to the official code base. That would explain it -- I use the wheel-mouse patches when I compile, and the beta-series patch must differ from the one I used when compiling the alpha series. I'll see if I can determine what's different and perhaps upload the new one. Thanks! Matthew
Re: beta3 and bbappconf iconic
On Tue, 2002-07-23 at 12:29, Ben Jansens wrote: On Tue, Jul 23, 2002 at 12:16:38PM -0400, Matthew Weier O'Phinney wrote: I'm not sure exactly when I started using bbappconf -- if it was with 0.62.1 or with an early 0.65 alpha. However, when I originally used it, running bbappconf -i wouldn't iconify bbappconf properly -- I'd get a little, blank, decorless window in my upper left screen on each workspace. As a result, I started using bbappconf -w so I at least wouldn't see it so much (I run my slit as autohide). Recently, in alpha8, I discovered it was once again iconifying properly. Then, today, when I upgraded to beta3, it reverted to it's weird behavior once again. Is this a problem with bbappconf? Or is there code that has changed and changed back again for the bbtools that would cause this behaviour? I don't notice the same thing happening with bbkeys, the only other bbtool I currently run, which leads me to believe it's a problem with bbappconf... Anybody else noticing this? figured out a patch? IIRC bbappconf hs never iconified right. I made a patch a long time ago for bbappconf. Grab it at http://xor.orodu.net/bb/bbappconf.move_resize_fix_iconify.patch Maybe that'll solve your problem. Thanks! It did! bbappMan now appears in my Icons list, and doesn't fuzz up either my screen or slit. Thanks a bundle! xOr -- I am damn unsatisfied to be killed in this way. On Tue, 2002-07-23 at 12:23, Sean 'Shaleh' Perry wrote: Where did you get bbappconf from? The source code is at: http://bbtools.windsofstorm.net/sources/devel/bbappconf-0.0.1-peak3.tar.gz and an unofficial Debian package can be found at: http://research.soc.staffs.ac.uk/~james/download/bbappconf_0.0.1-peak3-1_i386.deb I'd actually had the Debian package installed, so I had to search through Google to find the source code -- which is buried in the bbtools site, and never linked from their pages. It might be nice if someone -- perhaps the maintainers of the FAQ -- would inquire into getting permission to host the source and Debian packages on their site, so that this app won't get lost over time. --Matthew
RE: beta3 mouse shading
On Tue, 2002-07-23 at 12:17, Sean 'Shaleh' Perry wrote: On 23-Jul-2002 Matthew Weier O'Phinney wrote: I determined what changes I needed to make -- the beta series wheel mouse patch only applies to switching workspaces, and thus only affected Screen.cc; the original patch I had was from x0r, and also had code for the window shading and thus affected Window.cc. I determined where to insert the code, did so, compiled, and everything works beautifully now. Since I know others on the list like to use this particular patch, I've now got another question: how do I make the patch? I'm not a C programmer, and I don't normally create or use patches. Do I simply do a diff on my files versus the original source? basically. cd blackbox make distclean cd .. cp -a blackbox blackbox-orig cd blackbox hack hack hack make distclean cd .. diff -pruN blackbox-orig blackbox mystuff.patch the -pru option is the format I prefer, other projects may request -prc. Once you have your patch go to sf.net and place it on blackbox's patch tracker so others can enjoy. Thanks for the instructions! I've done this, and the patch is now uploaded to the sf.net patch tracker. --Matthew
RE: styles help...
On Fri, 2002-06-28 at 14:41, Sean 'Shaleh' Perry wrote: Some things that were neat/appealing about it were: 1) he had made the window title bar semi-transparent 2) he'd put images into the menu background 3) the menu was semi-transparent, too. this semitransparency is implemented by XFree 4.x's new Xft library. It only works under Xfree 4.x and no where else. it is also resource intensive (memory + cpu). This is 100% a Waimea feature and is not in blackbox, nor will it be added. Thanks for the info, Shaleh. I wasn't quite sure how that stuff was being implemented, nor what it would mean for resources -- and since mine are few (366Mhz machine with 96MB RAM), I'll skip it for now. In the meantime, I've managed to create a very nice looking theme, err, style! --Matthew
wheel-mouse scrolling through workspaces in alpha8
I decided, after all the fun discussion on the list lately, to try out alpha8. After compiling and going into X, I realized I hadn't applied the wheelmouse patch I'd been using on 0.62.1 (which allows you to scroll through your workspaces using the mouse wheel)... However, when I went to look at the patch and possibly recompile, I realized that it appears to be specific to 0.62.1. Is this true? or can I apply that patch to the alpha8 code without a problem? I use this functionality quite a bit, so I'd like to try it out... --Matthew
Re: wheel-mouse scrolling through workspaces in alpha8
On Thu, 2002-06-06 at 10:08, xOr wrote: On Thu, Jun 06, 2002 at 09:49:46AM -0400, Matthew Weier O'Phinney wrote: I decided, after all the fun discussion on the list lately, to try out alpha8. After compiling and going into X, I realized I hadn't applied the wheelmouse patch I'd been using on 0.62.1 (which allows you to scroll through your workspaces using the mouse wheel)... However, when I went to look at the patch and possibly recompile, I realized that it appears to be specific to 0.62.1. Is this true? or can I apply that patch to the alpha8 code without a problem? I use this functionality quite a bit, so I'd like to try it out... Try this one out. It applies to last night's cvs (so it will today too:) patch -p0 mouse_wheel.diff http://www.orodu.net/~xor/bb/ob-bb/mouse_wheel.diff Thanks! It works exactly as expected! --Matthew xOr -- I am damn unsatisfied to be killed in this way.
Re: wheel-mouse scrolling through workspaces in alpha8
On Thu, 2002-06-06 at 11:53, Matthew Weier O'Phinney wrote: On Thu, 2002-06-06 at 10:08, xOr wrote: On Thu, Jun 06, 2002 at 09:49:46AM -0400, Matthew Weier O'Phinney wrote: I decided, after all the fun discussion on the list lately, to try out alpha8. After compiling and going into X, I realized I hadn't applied the wheelmouse patch I'd been using on 0.62.1 (which allows you to scroll through your workspaces using the mouse wheel)... However, when I went to look at the patch and possibly recompile, I realized that it appears to be specific to 0.62.1. Is this true? or can I apply that patch to the alpha8 code without a problem? I use this functionality quite a bit, so I'd like to try it out... Try this one out. It applies to last night's cvs (so it will today too:) patch -p0 mouse_wheel.diff http://www.orodu.net/~xor/bb/ob-bb/mouse_wheel.diff Thanks! It works exactly as expected! Ooops!!! Spoke too soon. Actually, it works fine -- but the direction is off: The wheel scrolls through the workspaces in the opposite direction from what it used to do. (For example -- what would be scrolling up actually moves down a workspace, and vice-versa.) Not really a problem (I've already adapted) -- just a difference in functionality I thought I should point out. --Matthew --Matthew xOr -- I am damn unsatisfied to be killed in this way.
OT: versioning?
Okay, so this has really nothing to do with the development or use of a window manager, but it's something I've been curious about in my 2.5+ years of Linux experience: Why do most of the good X window managers have 0.xx versions after years of development? For example, I've used Enlightenment (various versions from 0.14.x through 0.16.5), WindowMaker (from versions 0.75 - 0.80.0), and currently BlackBox (various 0.6x versions). Why have none of them released a 1.x or above? I realize in part that most of these are under heavy or semi-heavy development all the time, but they also all are _very_ stable. Much more stable than kwm was when I tried it (admittedly, that was two years ago) or Sawmill/Sawfish, etc. XFCE has been in the 3.x series for awhile, and still has fairly heavy development and constant releases (I used this for over a year when I was using my laptop heavily -- obviously this was before I found blackbox!). What are the developers' thoughts on the matter? Matthew
Re: OT: versioning?
On Wed, 2002-06-05 at 11:46, Sean 'Shaleh' Perry wrote: What are the developers' thoughts on the matter? what makes 1.0 sound better than 0.60.2 or 10.3.1 or ab.de.e.4? In my experience the only important thing is that you can look at the version and compare it to the one you have and that there is a new revision somewhat often (depends on the project for what often means). I do not believe blackbox is heading for a 1.0 release. Or maybe it will. Either way it is just one more number in my book. Actually, it's not so much that 1.0 or 10.3.1 sound better -- for me it's that 0. at the beginning... If a 1.0 version is never planned or never likely, why use the 0. in the first place? Jamin talked of the stigma of a 1.0 release, but in my experience, both personally and professinally, a 0.x release has more stigma as it connotates a lack of stability. Some of my previous employers would never consider installing a 0.x (and typically even a 1.x) version of software based on this stigma. But this isn't even the point. My main question isn't even so much a criticism of using this practice -- it's actually more one of curiousity. Why choose one versioning/release scheme over another? For example, why would one developer like integer increments (1.x, 2.x, etc.) vs decimal increments? why would one developer prefer alphanumerics for their releases (1.xa, 1.xb, etc.)? What constitutes a reason for changing the numbering or increasing the version (i.e., why go from 6.2 to 7.0, for instance; or from 0.62.x to 0.65.x)? I'm curious in large degree because I've been professionally doing web programming for somewhere around 18 months now (and no, I'm not fresh out of college -- this was a career change for me) -- and I'm still trying to determine how I want to do versioning and releases for myself. I use CVS to keep track of my changes (and occasionally roll-back -- oof!) and often tag releases. At the company for which I work, we usually simply tag them with the particular date, a bid number, or project code, or combination of all three. In the end, I realize that the only important criteria is what works for me -- but I'm still trying to determine that -- and discussion such as this helps immensely. Thanks for the responses! Matthew The other key thing with revision numbers is they refer to a state of the code. This is why I have not wanted to add new items to the blackboxrc. 0.6x refers to a version of the rcfile as well. If I decided that 0.65.0 would be 1.0 and then went forward with a redesign as planned should the next one be 2.0? Why count from 1 to 10 when there are so many more numbers out there (-: Knuth's TeX (I believe) is an approximation of pi and every release he adds one more decimal place.
Re: A couple of (OT?) questions
On Sat, 2002-05-25 at 17:22, Scott Furt wrote: Es Bee Ex wrote: On Sat, 25 May 2002 20:30:20 +0100 Martin Rowe [EMAIL PROTECTED] wrote: 1. Is there a graphical app launcher that people recommend. ROX is a nice set of applications that together provide a FAST graphical desktop. I just use the ROX-Filer, but there is also an icon window, and taskbar, and other tools. http://rox.sourceforge.net I second this suggestion :) Rox is an amazing program. And I'll third it... Using the pinboard option, you can set up a desktop -- I've got this going now for some of my oft-used apps and also on my wife's desktop. There's a panel option that gives something similar to the XFCE panel -- a place to put icons for applications and a limited amount of menuing. I haven't used it, but it looks pretty slick. It _is_very_fast_. I'll never go back to GNOME or KDE! --Matthew
Window list question
Recently when somebody mentioned being able to tear away a submenu/menu from the menu or window list, I noted it and decided to keep that info for future use. Today I decided to use it -- I've got a browser window open, and several smaller windows as well that I often have covered by the browser window. Since I don't want to key through them all the time, and since I'm using my mouse anyway, I decided to tearoff the workspace menu for that workspace and put it in the upper right of the screen -- that way I can click on whichever app I need and immediately bring it to focus. Problem: I have several workspaces open, and I'll occasionally flip to another one to check my mail, open an app unrelated to the apps in my current workspace, etc. Unfortunately, the torn away workspace list stays present when I switch workspaces -- which is somewhat annoying, as it refers to a (now) different workspace... I'd prefer to have it stay on the workspace from which I called it originally, just as any other window there does. I'm using 0.62.1-1 on a Debian woody (unstable) machine. I'm assuming the behavior I'm seeing is normal -- but is there a feature request about this issue? Do others like it? would it be possible to have a choice between the omnipresent and workspace-only types? Is it in current development? Thanks, Matthew
Re: FAQ creation
On Mon, 2002-04-29 at 15:14, Jeremy C. Reed wrote: On Mon, 29 Apr 2002, Sean 'Shaleh' Perry wrote: Someone offered to make a FAQ recently, are you out there? I have a FAQ that I have sometimes maintained for a couple years now. My logs show it is visited around 310 times per week. It is google's first repsonse for blackbox faq. It still would have been nice for you to include the URI: http://www.reedmedia.net/misc/blackbox/faq.html Where'd my icons go!?!?! Covered. How do I set the desktop background?? Covered. Under Usage|How do I set the background you might add Esetroot -- it's compatible with Eterm, which is functionality many might be looking for. Can I use a keybinding to call the menu? Need to add (I think). Yes, you do. Basically, the answer is Not yet My blackbox faq uses a small script to generate it. It has been translated to Russian and I think it has been translated to Japanese. Jeremy C. Reed echo 'G014AE824B0-07CC?/JJFFFI?D64CBD=3C427=;6HI2J' | tr /-_ :\ Sc-y./ | sed swxw`uname`w By the way, I tried out all the links under the Patches section -- all of them are currently dead... :( Thanks for maintaining this -- I wish I'd seen it when I first began using blackbox... --Matthew
Re: Clicking URLs in Evolution under Blackbox
On Fri, 2002-04-26 at 05:18, Peter Peltonen wrote: I'm using blackbox-0.62.0-gjb1 under RH72. In evolution-1.0.3-2 I cannot click URLs to open them in a browser. Can this be done? My friend running GNOME can do this... Is Evolution too Gnome specific? Pretty much; it relies on GNOME to handle URLs, so you have to set them for GNOME. Fortunately, or not, depending on your point of view, in order to install Evolution, a bunch of GNOME core components have to be installed as well... and typically the GNOME Control Center is part of that installation. You'll need to go into it (run the program 'gnomecc' if you don't have it as a menu item for your distribution) and set the appropriate URL handlers. I've set mine to use galeon for http:// and https://, and gftp for ftp://. This works well for me in Blackbox 0.62.1-1. --Matthew -- Peter Peltonen System Administrator Fivetec Solutions Oy Melkonkatu 28 E 00210 Helsinki GSM. +358-40 720 6535 Tel. +358-9-6824 7666 Fax. +358-9-6824 7664 http://www.fivetec.com mailto:[EMAIL PROTECTED] --
Re: Resize Handles?
Try using bbkeys, and configuring key-combo to do horizontal and vertical increments/decrements... Example bbkeysrc lines: KeyToGrab(Left), WithModifier(Mod1+Shift), WithAction(HorizontalDecrement) KeyToGrab(Right), WithModifier(Mod1+Shift), WithAction(HorizontalIncrement) KeyToGrab(Down), WithModifier(Mod1+Shift), WithAction(VerticalDecrement) KeyToGrab(Up), WithModifier(Mod1+Shift), WithAction(VerticalIncrement) These would make alt-shift-(appropriate arrow key) increase/decrease either the height or width. I find it's easier than trying to manually do it with the mouse. Matthew On Tue, 2002-04-23 at 11:15, Es Bee Ex wrote: On a related note, does anyone else have a hard time resizing windows in one direction(or does anyone even want to do this)? Maybe it's just my mouse, but it's difficult to say, make a window 20 pixels taller. Any time I try, the window gets sized in both directions. I'm not sure how to change this behavior, but does someone else here have an idea? -- Joseph Applegate (SB-X) [EMAIL PROTECTED] | [EMAIL PROTECTED] UIN: 9788597
Re: Resize Handles?
On Tue, 2002-04-23 at 12:06, Es Bee Ex wrote: On 23 Apr 2002 10:36:48 -0400 Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: Try using bbkeys, and configuring key-combo to do horizontal and vertical increments/decrements... snip Yeah I've got that to ctrl-alt-shift, but it can it do 1pix at a time? :) That I don't know... anybody else? --Matthew -- Joseph Applegate (SB-X) [EMAIL PROTECTED] | [EMAIL PROTECTED] UIN: 9788597
odd window resize behaviour with applixware
I was following the thread about the emacs resizing, and remembered something that I've been having problems with for a while now. A couple years ago, I ponied up the cash for Applixware Office, and 3 or 4 Linux distros and uncountable window manager changes later I'm still using it -- it works for all my needs. HOWEVER, I noticed once I started using blackbox a few months ago that there's an odd behavior when I resize windows from the various Applix applications. First off -- when it loads, it comes in at a default size -- from what I can tell on my screen, it's about 750 px tall, maybe 400 px wide. However, when I try to resize it, it jumps to some unknown maximum size -- I think around 1280x1024; all I know for certain is it's bigger than my 1024x768 desktop -- and I am unable to size it back down. As a result, I've stopped even trying to resize these windows... but I am NOT going to leave blackbox -- it's the lightweight, powerful, beautiful window manager I've been looking for since I began my Linux odyssey! Applixware is built on the GTK+ toolkit -- and I use plenty of other GTK applications that don't have this problem (Galeon, Evolution, Pan, GAIM, etc.). Any ideas, anyone? Matthew
Re: odd window resize behaviour with applixware
On Thu, 2002-04-18 at 09:29, Tom Eliaz wrote:
On 18 Apr 2002, Matthew Weier O'Phinney wrote:
snip
As a result, I've stopped even trying to resize these windows... but I
am NOT going to leave blackbox -- it's the lightweight, powerful,
beautiful window manager I've been looking for since I began my Linux
odyssey!
As a small aside to your main point, do your windows not resize (you say
you are unable to size them back down)?
I usually alt-{right mouse click}
Derek C. wrote and said this as well -- I should have mentioned that
neither this worked, nor resizing using the corner-bars.
or you can set the appropriate hints in .bbkeysrc if you use that. For
example I have:
KeyToGrab(Up), WithModifier(Shift+Control), WithAction(VerticalDecrement)
KeyToGrab(Down), WithModifier(Shift+Control),
WithAction(VerticalIncrement)
KeyToGrab(Left), WithModifier(Shift+Control),
WithAction(HorizontalDecrement)
KeyToGrab(Right), WithModifier(Shift+Control),
WithAction(HorizontalIncrement)
HOWEVER -- this DID work -- I do use bbkeys, but mainly for switching
workspaces and windows. Thanks for the idea -- it will certainly keep me
sane!
No, it doesn't fix the bug, but it will keep you sane until then :) Do
these methods work?
Sorry for the tangent, hope it helped.
Tom Eliaz
edgesnap patch
So I recompiled blackbox with the edgesnap and wheelmouse patches today, and everything went smoothly. The mouse wheel now allows me to scroll between workspaces with ease, and I like that a lot. I'm a little mystified by the edgesnap patch -- I thought I understood its purpose, but I think when it comes down to it I don't... or at least, it's not doing as I expected... I expected it to allow windows to snap to the workspace edges...? --Matthew
iconify a program on startup?
I'd like to iconify evolution on startup, and I'm not sure how to do so. (I use gkrellm, and I can have it easily open my inbox if evolution is iconified, as well as create a menu item/gnome URL handler to open up a compose message box... I just don't want to see it after startup all the time, and it takes too long to load otherwise...) I'm starting the program via my .xinitrc, and I've tried the following: wmswallow evolution evolution (didn't work) bblaunch -w 3 evolution --no-splash (doesn't throw it to the appropriate workspace, and doesn't iconify it) Is there any other way to do this? Thanks, Matthew
Re: iconify a program on startup?
On Sat, 2002-04-06 at 17:14, Sean 'Shaleh' Perry wrote: I'm starting the program via my .xinitrc, and I've tried the following: wmswallow evolution evolution (didn't work) wmswallow tries to put it in the slit, I doubt you want that. bblaunch -w 3 evolution --no-splash (doesn't throw it to the appropriate workspace, and doesn't iconify it) once you have blackbox launched, try that same command line from a term window. My guess is evolution takes longer to load than bblaunch's timeout setting. If the window does not open in N time bblaunch gives up and closes. You most likely need to experiment with it to find the right amount of time. But is it possible to have a window open iconified? That's what I'd like, ideally...
Re: iconify a program on startup?
On Sat, 2002-04-06 at 17:42, Sean 'Shaleh' Perry wrote: once you have blackbox launched, try that same command line from a term window. My guess is evolution takes longer to load than bblaunch's timeout setting. If the window does not open in N time bblaunch gives up and closes. You most likely need to experiment with it to find the right amount of time. But is it possible to have a window open iconified? That's what I'd like, ideally... bblaunch has a open iconified flag. okay... maybe I'm missing something, but I've read the documentation for bblaunch (I'm using 0.0.1-2 for Debian), and I can't see anything about an iconified flag... Are you talking about -s (shaded)? Thanks!
Re: iconify a program on startup?
On Sat, 2002-04-06 at 18:04, Sean 'Shaleh' Perry wrote: okay... maybe I'm missing something, but I've read the documentation for bblaunch (I'm using 0.0.1-2 for Debian), and I can't see anything about an iconified flag... Are you talking about -s (shaded)? my mistake, it does not have this feature. Would not be too hard to add. Will try to code it up in a day or three. Thanks! I did finally get a good pause time for the -p option (somewhere between 16 and 20 seconds when I load it via .xinitrc; less than 8 if I do it manually after everything else is loaded; theese are the reasons I want to start it on loading X!), and I have it shade into workspace 4... in a line: bblaunch -s -w 4 -p 2 evolution --no-splash This works very well, actually -- tho' I wouldn't mind an iconify feature (programs like gaim are nice to start iconified)... I'll look for your announcement of its availability -- and, in case I forget to say it then, Thanks! Matthew
slit functionality...
I've only been using blackbox for a few months, but it is certainly my favorite WM in the more than two years I've been using Linux. My only beef with it so far is the slit... and not so much how it looks or works, but how programs are loaded into it. I've searched through the archives, and seen the hacks people have done to get dockapps, bbtools, and whatnot to load in a specified order, and to date I have been unable to get 100% compliance on my machine. About 1 in 4 times or more, the apps I load into it come in a randy order. I saw somewhere, when I was first trying out blackbox, a little application somebody had written to insure that apps came in in the appropriate order... but since I didn't know what that meant at the time, I ignored it and promptly lost the URL. I've tried hacks like: bbrun sleep 1 bbpager sleep 1 wmusic etc., but these are not consistent. Any _other_ ideas anyone? Thanks, Matthew
Re: slit functionality...
On Tuesday 02 April 2002 15:08, Derek Cunningham wrote: Agreed... _I_ don't really care anymore, since I've found gkrellm, it solves all of my problems (well, except for bbpager, and bbkeys is iconified). ... DC Last I'd tried GKrellM, I hated it -- but I just checked it out again, and I have to say I'm very impressed -- I'm able to do everything I was doing with dockapps inside it, and then some (except for bbpager, which you also noted). However, I _would_ like to put this in the slit as I use multiple workspaces. I just tried wmswallow as follows: wmswallow gkrellm gkrellm ...and got a truncated gkrellm inside the slit. How do I get the full app to show up? --Matthew
