Re: bbconf 1.8 configure error(libqt3 detection)
Umm. Author here. Since It Works For Me (TM), I'll accept patches. =:) Actually, I believe that I snarfed the auto* magic from the latest kde3 tree, so Øyvind, I'd be curious to see if you can build kde3 either. On Thu, 2002-07-18 at 11:55, Øyvind Stegard wrote: > Sean 'Shaleh' Perry wrote: > > >>>unless you have libqt-mt-devel or whatever your dist calls it the configure > >>>script won't find it. > >>> > >>> > >>> > >>> > >>> > >>> > >>Yep, like I said, I have all the development files installed as well. > >>(libqt3-devel-3.0.4 package). I also jsut noticed that someone has filed > >>a bug on the same problem at bbconf.sf.net. > >> > >> > > > >you are missing the point. libqt3-devel is NOT libqt3-mt-devel. Their > >configure script expects you to have installed the mt lib and devel. > > > > > > > > > OK, I see..Hm.. So there should be a package named libqt3-mt-devel > somewhere, or libqt3-mt ? That's strange, since all my searches result > in the libqt3 package, which does contain a multithreaded library (I've > checked), together with a libqt3-devel package(which also contains a > QThread.h file in the includes-dir, which I assume has something to do > with the multithreading features?). Searching for libqt-mt-devel gives > no results on Google/linux, rpmfind.net nor Mandrake's website(s). > > Perhaps I must go to Trolltech and get their free version and compile > the whole monster it to make it work ? =) > > I find no indication that there is a libqt3-mt-devel rpm package > anywhere. I might, of course, be totally wrong, but it seems so. Any > more tips would be greatly appreciated, since I'm a bit confused right > now and would like to get bbconf up and running. > Thanks.. > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:22-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
new bbconf release - 1.8
re, all bbconf 1.8 is set loose. This fixes a small buglet in the keybinding editor whereby you'd go, like, hey, add me one of them command thingeys, and bbconf would go, like, sure, dude, but wouldn't really do anything. Or something like that anway. Also, new with this release, I've gotten Congress's approval to stop building RPMs and .deb's. I've made it so danged simple to do it that it's just a waste of my time for me to do it myself. If you want a .deb, either wait for the good shaleh to package it, or type "make dist-deb". That easy. If you want an RPM, type "make dist-rpm". Go get it! This one has a hidden 300 meg MPEG movie in it!!! -- ,-------------// | Jason 'vanRijn' Kasper :: Numbers 6:22-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: new NETWM key grabber
On Thu, 2002-07-11 at 08:57, Derek Cunningham wrote: > On Wed, Jul10,02 22:35, Ben Jansens wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wednesday 10 July 2002 10:33 pm, Derek Cunningham wrote: > > > On Wed, Jul10,02 22:16, Ben Jansens wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > Hey folks. > > > > > > > > So, work has begun as of tonight on a next generation key handler for > > > > blackbox. It will be written against the NETWM spec as much as possible. > > > > But, we're not sure just what kind of feature people out there want in > > > > their keyhandler. So, I'd like to take a bit of a poll. > > > > > > > > Do you use the window list cycling currently found in bbkeys? > > > > > > yes I do... but it's useless, for me at least. > > > > > > What I WOULD like to see is an emacs-like ability to string characters > > > together. ie: CTRL+Z+R will perform some action, and CTRL+Z+T will perform > > > some other action. Think that's doable? > > > > Thats in the todo list. So, yes. :) > > I should note that after reading through the other responses, I > misunderstood what you meant by "window list cycling". I use ALT+TAB all the > time, and I use ALT+(1|2|3|...) all the time too, so an emphatic YES to > window list cycling. :) > > DC > > PS: I had thought you meant the stupid little list that pops up WHILE > cycling windows. :) Heh. Careful, matey. xOr's the one who helped me put that "stupid little list" in. =:) I happen to love it. *shrug* One man's stupid is another man's most favoritest new toy. > > -- > Derek Cunningham > [EMAIL PROTECTED] > > "Human beings act intelligently only after they have > exhausted the alternatives" -- Abba Eban > > Registered Linux User Number 195825 > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:22-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: BBConf and Meta keys
Yay! Inherited bug! =:D On Tue, 2002-06-04 at 18:04, Jamin W.Collins wrote: > On Tue, 04 Jun 2002 07:45:46 -0700 (PDT) > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > > > Jamin, if you try out an app like 'kate' it has a very similar key > > grabber. That would help track down the problem. > > Same exact problem exists in 'kate'. If the keyboard is set to pc-101 > then regardless of whether the keys are defined and seen by 'xev' > properly, they are not seen by 'kate'. > > -- > Jamin W. Collins > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: BBConf and Meta keys
Nope. =:) The keygrabber widget is one I snarfed from kde's tree and I had to modify it slightly to get it to work, being that it isn't running in a KApplication. Chances are, I missed something that's otherwise there in a running KDE environment. Patches accepted here. =:) On Tue, 2002-06-04 at 08:11, Jamin W.Collins wrote: > On 04 Jun 2002 07:49:55 -0400 > "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> wrote: > > > er. So, I was just going to ask for a patch. =:) But it looks like > > bbconf is working correctly? > > Well, yea. But, any ideas why it wouldn't see keys (assigned via xmodmap) > that xev does? > > -- > Jamin W. Collins > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: BBConf and Meta keys
er. So, I was just going to ask for a patch. =:) But it looks like bbconf is working correctly? On Mon, 2002-06-03 at 15:01, Jamin W.Collins wrote: > On Mon, 03 Jun 2002 10:02:06 -0700 (PDT) > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > > > I just played around with bbconf and it does read my meta key. Dunno > > why Jamin is having problems. > > Looks like the problem was due to my XF86Config-4 file (carry over from > Red Hat configuration). The keyboard was set to pc101 instead of pc104. > It's strange though that xev was seeing things correctly when I assigned > the keys via xmodmap, but bbconf wasn't. > > -- > Jamin W. Collins > -- ,-----// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
bbconf 1.6 hereby released into the wild...
Right. Due to the overwhelmingly non-existent response to my previous bbconf 1.6-pre e-mail, I'm hereby releasing bbconf version 1.6. It has many, many wonderful changes with many, many wonderful new features and abilities and many, many wonderful enhancements! I'll paste the relevant portion from the ChangeLog below Do be a good chap/chapette and go to http://bbconf.sourceforge.net and download the little guy! He's lonely and has VERY good manners!! ChangeLog - version 1.6:: - fixed layout issues so we now fit into 800x600 screen size, yay! [vanRijn] - using the proper QPaintDevice::x11AppDisplay() rather than qt_xdisplay(), and RootWindow(QPaintDevice::x11AppDisplay(), QPaintDevice::x11AppScreen()) instead of qt_xrootwin() throughout the project now... (thanks for the Qt-down-low, nyz! =:) [vanRijn] - now using blackbox's pid to ask him to reconfigure rather than doing 'killall -HUP blackbox', which at best is undesirable and at worst is VERY un-neighborly (it's not nice to init 0 SCO boxen unannounced). We now use the _BLACKBOX_PID atom on the root window to get the pid and kill -HUP it. Yay! [vanRijn] - fixing installation directory for bbconf's plugins. Previously, we stuck these in $(datadir). These now go in $(prefix)/lib/bbconf/plugins. [vanRijn] - fixing bbconf to understand "~" better. Ported blackbox's expandTilde() to QString. Still don't do "~user", but we're better than we were. =:) Thanks to Nate Smith for bug reporting! [vanRijn] - okay, big change... Qt 3.0.3 or > is required for bbconf now. =:) There's more reasons that I care to list for this, but they're all really good. =:) [vanRijn] - pulling in newer and improved-er =:) acinclude.m4, ltconfig, and ltmain.sh from kde3 directories. Hopefully this will allow Brad to compile now. =:) [vanRijn] - fix for style-setting changes. Also, we now dynamically load the list of available styles and populate our look and feel dropdown based on what's really available on the system, rather than hard-coding it. [vanRijn] - okay, more build fixes for FreeBSD. FreeBSD calls qt2's moc "moc2". I'm curious to see what havoc we'll wreak with qt3. libqt3.so? moc3? Thanks to Kyle Donaldson for the bug reports. =:) [vanRijn] - build fix for redhat boxes (?)--gzipping the man page [vanRijn] - taking out "(experimental)" from the --enable-mt directive [vanRijn] - hopefully fixing the layout issues where we were taking up rather large amounts of screen real estate (which was not very nice of us) [vanRijn] - fixing kckey.cpp (lower/upper-case issues) (was stopping people from being able to use comma, period, space, etc. for keybindings) [vanRijn] - fixing Makefile.in's for NetBSD builds (probably others too)--we had LDFLAGS overridden in all the plugin Makefiles (why, I don't know). Thanks to Thomas Klausner for the bug report. [vanRijn] What are you waiting for??? GO GET IT!!! -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: bbconf 1.6-pre
On Sun, 2002-05-26 at 03:39, Sean 'Shaleh' Perry wrote: > > On 26-May-2002 Sean 'Shaleh' Perry wrote: > >> > >> If you're interested, check out the CVS version of bbconf (see > >> http://bbconf.sourceforge.net for CVS access directions). Thanks! =:) > >> > >> - version 1.6:: > >> - fixing bbconf to understand "~" better. Ported blackbox's > >> expandTilde() to QString. Still don't do "~user", but we're better > >> than we were. =:) Thanks to Nate Smith for bug reporting! > >> [vanRijn] > >> > >> - okay, big change... Qt 3.0.3 or > is required for bbconf now. =:) > >> There's more reasons that I care to list for this, but they're all > >> really good. =:) > >> [vanRijn] > >> > > > > note for the Debian users in the crowd. You need libqt3-mt-dev and libqt3-mt > > to compile bbconf. > > > > (/me waits patiently for the compile to finish) > > compiles fine right out of cvs, no need to touch anything. Launches ok too. > Everything looks good. > Sweet mama!! Shaleh is actually able to compile my Qt code!?!?!?! =:) Any FreeBSD users out there? -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
bbconf 1.6-pre
Okay then. I don't know if anyone on the list uses bbconf, but if you do... I'd really appreciate it if you could check out bbconf 1.6-pre when you get a chance. There's some serious bug-squashing and feature enhancements in this pre-release. I'll paste the relevant section of the ChangeLog below I've updated a bunch of the build logic, so please let me know if you have ANY issues with building bbconf (*cough* nyz *cough*). =:) I'd like to get it right before I release 1.6 into the wild. If you're interested, check out the CVS version of bbconf (see http://bbconf.sourceforge.net for CVS access directions). Thanks! =:) - version 1.6:: - fixing bbconf to understand "~" better. Ported blackbox's expandTilde() to QString. Still don't do "~user", but we're better than we were. =:) Thanks to Nate Smith for bug reporting! [vanRijn] - okay, big change... Qt 3.0.3 or > is required for bbconf now. =:) There's more reasons that I care to list for this, but they're all really good. =:) [vanRijn] - pulling in newer and improved-er =:) acinclude.m4, ltconfig, and ltmain.sh from kde3 directories. Hopefully this will allow Brad to compile now. =:) [vanRijn] - fix for style-setting changes. Also, we now dynamically load the list of available styles and populate our look and feel dropdown based on what's really available on the system, rather than hard-coding it. [vanRijn] - okay, more build fixes for FreeBSD. FreeBSD calls qt2's moc "moc2". I'm curious to see what havoc we'll wreak with qt3. libqt3.so? moc3? Thanks to Kyle Donaldson for the bug reports. =:) [vanRijn] - build fix for redhat boxes (?)--gzipping the man page [vanRijn] - taking out "(experimental)" from the --enable-mt directive [vanRijn] - hopefully fixing the layout issues where we were taking up rather large amounts of screen real estate (which was not very nice of us) [vanRijn] - fixing kckey.cpp (lower/upper-case issues) (was stopping people from being able to use comma, period, space, etc. for keybindings) [vanRijn] - fixing Makefile.in's for NetBSD builds (probably others too)--we had LDFLAGS overridden in all the plugin Makefiles (why, I don't know). Thanks to Thomas Klausner for the bug report. [vanRijn] -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: read GNOME/KDE desktop files?
http://menushki.sourceforge.net/ Just make sure you don't have "/" in your menus to convert. =;) On Mon, 2002-04-29 at 02:44, thelupine wrote: > > Derek Cunningham declaimed: > > > On Sun, Apr28,02 20:12, Sean 'Shaleh' Perry wrote: > > > > Has anyone written a program to read the .desktop > > > > files that GNOME and KDE use to generate their menu > > > > from? > > > > GNOME -> blackbox menu program would be nice to have > > > > and help out new converts. Should take about an hour > > > of python/perl/tcl coding. > > > Someone want to send a copy of their GNOME file over, > > > and I'll have a look at it. > > > > > I'd be glad to help test this. I manage a small (10 CPUs) > > lab. Right now they're all running RH 7.2/Gnome/Sawmill. > > I've been installing blackbox for my own use, but don't > > run Gnome. A summer project while the lab is empty is to > > rebuild to a standard config. I might be stuck with RH, > > but I can certainly put Blackbox in. > > > > Regards, > > > > Paul > > -- > > Paul Mackinney > > [EMAIL PROTECTED] > > It took a little work, but I've been able to run BB with > RH7.2 and Gnome smoothly for weeks now. I'm still new to > all of this and learning, but if there is anything I can do > to help, let me know. I might have come across something > already, that you might come across as well. And vice > versa..hint hint. ;-) > > -Lup > > - > ..:TheLupine:.. > http://welcome.to/thelupine > ----- > > _ > // free anonymous email || forums \\ subZINE || anonymous browsing > subDIMENSION -- http://www.subdimension.com > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: Focus stuff..
On Tue, 2002-04-23 at 21:36, Joe MacDonald wrote: > In message: Re: Focus stuff.. (<Pine.GSO.4.44.0204231924260.9560-10@sabaki>) > on 23/04/2002 (Tue 19:27) William K Baran wrote: > > > Hateful feature? Following the thread.. it seems that feature would > > allow some of us to completely shed the mouse. > > Not necessarily a bad thing in and of itself, actually a quite admirable > goal. I'm not a big fan of mousing around to do everything, but the > only thing I dislike more than windows popping up and stealing my focus > is windows popping up and moving my mouse pointer (and thus stealing my > focus). :-) > > > Now if I can just convince bbkeys to add arbitrary key remappings that > > modmap won't do (that I konw of). Ahh.. the dream of replacing > > arrow-keys and mouse events with Meta+Vi-keybindings.. > > .. . . Now that sounds pretty sweet to me too. Sign me up for some of > that if the bbkeys author is listening. > er. speaking. Um. What are you looking to do? bbkeys will XGrabKey on anything X considers a key, but obviously, since the whole things runs in X, if X doesn't know it exists, bbkeys doesn't either. > -Joe. > > -- > Joe MacDonald > :wq > -- ,-// | Jason 'vanRijn' Kasper :: Numbers 6:24-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `--//
Re: slit functionality...
In blackbox, only, use the code I contributed to gkrellm. =:) *injuring arm patting self on back*. First, make sure that you have "remember screen location at exit amd move to it at next startup" UN-checked in gkrellm's configuration. Then, restart gkrellm with "gkrellm -w" and gkrellm will fit quite nicely in blackbox's slit. On Tue, 2002-04-02 at 16:37, Matthew Weier O'Phinney wrote: > 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 > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys blew up on me
KDE3 works beautifully though!!! =:D On Thu, 2002-03-28 at 21:41, Derek Cunningham wrote: > hmm... that's funny... ALT+Mouse1 wasn't working either... hitting other > keys a few times seems to have brought things back to life. wtf? > > DC > > On Thu, Mar28,02 21:37, Derek Cunningham wrote: > > Blackbox list... I've been running bbkeys v0.3.5 for some time now (over 6 > > months, at least!) and just the other day... it blew up. *sniff* *sniff* it > > was working fine, now, it's not. > > > > I'm compiling 0.8.4 as we speak (err, I type, you read, then again, it's > > probably done compiling by the time you read this), which I hope will fix > > the problem. > > > > I'm running Blackbox 0.6.2, any ideas why bbkeys 0.3.5 would blow up? > > > > DC > > > > -- > > Derek Cunningham > > [EMAIL PROTECTED] > > > > "Human beings act intelligently only after they have > > exhausted the alternatives" -- Abba Eban > > > > Registered Linux User Number 195825 > > -- > Derek Cunningham > [EMAIL PROTECTED] > > "Human beings act intelligently only after they have > exhausted the alternatives" -- Abba Eban > > Registered Linux User Number 195825 > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbconf segmentation fault
On Fri, 2002-03-15 at 08:29, Alexander Volovics wrote: > On Fri, Mar 15, 2002 at 08:11:53AM -0500, Jason 'vanRijn' Kasper wrote: > > > On Thu, 2002-03-14 at 18:00, Alexander Volovics wrote: > > > > On Thu, Mar 14, 2002 at 09:36:02PM +0100, Yvon Thoraval wrote: > > > > > when rebuilding bbconfxxx.src.rpm, i get the followin error : > > > > > > > > RPM build errors: > > > > File not found: /var/tmp/bbconf-1.4/usr/man/man1/bbconf.1 > > > > You probably have to edit the bbconf.spec file and include something > > > like the lines: > > >cd $RPM_BUILD_ROOT/%{prefix}/man > > >[ -f man1/bbconf.1.gz ] || gzip man1/bbconf.1 > > > after the line: > > ># Build the file-list automagically :) > > > > Um. This doesn't make sense. It seems that the build process is > > failing because it's looking for "man1/bbconf.1", not > > "man1/bbconf.1.gz". Why would it fix things to gzip the man page? And > > I'm honestly very confused as to why this would fail anyway, since the > > %files list is generated dynamically based on what files are actually > > there. > > I can't explain it. I am not an rpm guru. > > All I can say is that under RedHat (7.2) the rpm macros seem to want > to find a "man1/bbconf.1.gz" in the BUILD_ROOT and not "man1/bbconf.1". > (all the man's included in the installed distro are gzipped). > > When rebuilding the bbconf src.rpm I got the same message as > Yvon Thoraval: "File not found: /var/tmp/bbconf-1.4/usr/man/man1/bbconf.1" > > When I gzipped the man page first everything worked perfectly. > > Alexander Hm. *muttering foul words regarding RPMS* Okay, I've changed this and put it into CVS. Can someone please pull down 1.6-pre from CVS when you get a chance and give this a shot? (cvs update && ./configure && make dist-rpm) Please let me know > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbconf segmentation fault
On Thu, 2002-03-14 at 18:00, Alexander Volovics wrote: > On Thu, Mar 14, 2002 at 09:36:02PM +0100, Yvon Thoraval wrote: > > > when rebuilding bbconfxxx.src.rpm, i get the followin error : > > > > RPM build errors: > > File not found: /var/tmp/bbconf-1.4/usr/man/man1/bbconf.1 > > > > and launching gives : > > > > [root@yvon BB]# bbconf > > Segmentation fault (core dumped) > > > > i understand i'm missing something but what or where could i find info on bbconf ? > > You probably have to edit the bbconf.spec file and include something > like the lines: >cd $RPM_BUILD_ROOT/%{prefix}/man >[ -f man1/bbconf.1.gz ] || gzip man1/bbconf.1 > after the line: ># Build the file-list automagically :) > Um. This doesn't make sense. It seems that the build process is failing because it's looking for "man1/bbconf.1", not "man1/bbconf.1.gz". Why would it fix things to gzip the man page? And I'm honestly very confused as to why this would fail anyway, since the %files list is generated dynamically based on what files are actually there. Anyone able to explain this annoying little feature of RPM-building? Anybody else seeing this? > It was missing from the last bbconf.spec file I saw (bbconf-1.4). > > Alexander > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: blackbox-0.62.1-custom_titlebar-fab.patch
If it's up for a vote, I vote 'aye'. =:) On Sat, 2002-03-02 at 23:37, Sean 'Shaleh' Perry wrote: > On 03-Mar-2002 Marc Wilson wrote: > > Ok, here's another one that shaleh says is never gonna make it into > > blackbox... > > > > actually, I am on the fence on this one. It may make it in .. > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: goofy blackbox/bbkeys interaction
Use KDE2. On Wed, 2002-02-27 at 10:11, Jan Schaumann wrote: > David Terrell <[EMAIL PROTECTED]> wrote: > > I have focusNewWindows set to true and focusLastWindow set to False. > > (I don't know if these settings are germane to my problem...) When > > I alt-tab in bbkeys and the window list popup happens to be under > > the mouse cursor, focus always ends up in the window where the mouse > > cursor is after I release alt, regardless of where I alt-tabbed to. > > We've discussed this a few times here on this list (check the archives), > and I don't think we've come to a solution. The problem lies, > obviously, in the mouse-focus event the window under the window-list > receives when the window-list disappears. > > The workaround would probably entail convincing blackbox/bbkeys that the > window-list is not a window, so that the mouse-focus does not change > when the pointer is over it. How tricky to implement this might be, I > can not comment on. > > -Jan > > -- > finger [EMAIL PROTECTED] > Please do not CC me when replying to messages on a Mailing List. > See Mail-Followup-To header (above) and > http://www.google.com/search?q=Mail-Followup-To+Header > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: quake3/gaim in bb
Um. I've of course deleted the original message, but I believe the message started along the lines of "how come gaim raises itself above quake...", etc. It seems to me that the correct and simplest solution to this is to tell gaim to stop XRaiseWindow'ing itself to the top whenever it feels like it (Conversations | IM Window -> "Raise windows on events") Since quake isn't setting anything that tells window managers to not allow other windows to overlay it, I don't think this is the window manager's job On Wed, 2002-02-06 at 16:55, Sean 'Shaleh' Perry wrote: > On 06-Feb-2002 Jamin W. Collins wrote: > > On Wed, 2002-02-06 at 15:17, Sean 'Shaleh' Perry wrote: > >> On this topic (forgive me I am not a gamer and generally do not own cool > >> enough > >> hardware to run most games) what does 'fullscreen mode' mean? Is this > >> something like DGA? I suspect I will have to track down the source and > >> look. > > > > Not sure of the complete technical breakdown in terms of what it means > > to Blackbox, but in essence "Fullscreen" items take over the complete > > display (no decoration of any kind). I don't believe this requires > > DGA. If it would help, I could whip up a really minor fullscreen SDL > > application (any video card should be able to run it) for testing with. > > > > Jamin W. Collins > > hm, on initial reading of the SDL code they simply raise the window to the > top and make it cover the whole screen. Near as I can see they set no special > hint or flag letting the wm know this. > > Best thing blackbox could do at that point would be refusing to raise the > dialog if the parent was not visible. But then that raises other issues. Not > sure what the right approach is here. > -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: PATCH - a small bug in option handling
Thanks again, Roman!!! =:) Fixed. On Tue, 2002-02-05 at 05:36, Roman Neuhauser wrote: > looks like there's a typo in src/main.cc: bitwise OR instead of logical > one. > > -- > FreeBSD 4.4-STABLE > 11:35AM up 15 days, 17:58, 9 users, load averages: 0.00, 0.04, 0.04 > > > Index: src/main.cc > === > RCS file: /cvsroot/bbkeys/bbkeys/src/main.cc,v > retrieving revision 1.3 > diff -u -r1.3 main.cc > --- src/main.cc 2002/01/13 18:59:39 1.3 > +++ src/main.cc 2002/02/05 10:22:34 > @@ -85,7 +85,7 @@ > exit(2); > }; > options.bbkeysrc=argv[i]; > - } else if ((!strcmp(argv[i], "-nobb")) | (!strcmp(argv[i], "-n"))) { > + } else if ((!strcmp(argv[i], "-nobb")) || (!strcmp(argv[i], "-n"))) { > options.nobb_config = True; > } else if ((!strcmp(argv[i], "-v")) > || (!strcmp(argv[i], "-version"))) { -- %<--%< Jason 'vanRijn' Kasper bash$ :(){ :|:&};: Numbers 6:24-26
Re: Feature request for bbconf (and/or whiteBOX)
On Wed, 2002-01-30 at 13:37, Johan Ronström wrote: > Hello > > I don't know who's doing the work with bbconf but I have a few suggestions for > future features: Um, well, I think I've littered mine and xOr's e-mail links all over http://bbconf.sourceforge.net, but anyway > > It would be nice if you could change the way the clock in the toolbar shows the > time (just the time or the whole date stuff, or 24h clock). As soon as blackbox's config-change/rc-file-rewriting behavior is changed so that it writes its rc-file immediately when its configuration changes, rather than insisting on writing its rc-file every time it exits, then I will write a bbconf plugin to allow you to configure everything in blackbox's rc-file. This will include: - slit placement, direction, auto-hide, ontop behavior - toolbar placement, ontop, width, autohide, etc. - all of blackbox's config menu options - workspace names - window placement behavior - focus model - clock format (humanly-configurable as well as directly supporting strftime format strings) - style file directives - etc., etc., etc., ad nauseum But it's pointless for me to do so while blackbox insists on overwriting its rc-file everytime it exits. =:) So... *looking back at the question* oh yeah--um. yes. =:) > > Another thing is that the menu editor doesn't support swedish characters so I > have to change it in my .bbmenu after avery change in bbconf (not really > important, but...) Hm. I'm not sure what the solution is for this. Anyone with qt-savvy able to look through bbconf and see where it's amiss with regards to multiple-languages? > > I had some more that I cannot remember right now... > > By the way, I can't figure out how the 'Styles menu' in the menu editor > works... Could someone explain (I use the Styles directory under a submenu). > So do I. For example, in my menu file, I have a submenu item (in bbconf, click new item and change its type to submenu) called "bbox Private Styles". Then click "new child item", change its type to "styles directory" and next to the "directory of styles" textbox, click the button with 3 dots on it to browse for the directory that you want to use as your styles directory. Of course, you're also able to just type the directory name in too. =:) That's pretty much it. > Thanks. > > __ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: website, let's get the decision made
Well, since 4 and 5 are slash^H^H^H^H^Hblackbox-mailing-list-dotted and I can't see 'em, I think my preferences are 3 then 1. Thread did a fantastic job on 3 and I like the subtle differences between it and 1. On Sat, 2002-01-26 at 11:28, Sean 'Shaleh' Perry wrote: > 1) http://www.planetquake.com/lvl/blackbox > > 2) http://www.threadbox.net/blackbox > > 3) http://www.threadbox.net/blackbox/lightgfx.html > > 4) http://speed.seas.upenn.edu/~rarya/bb2/ > > 5) http://speed.seas.upenn.edu/~rarya/bb/index.html > > 6) http://furt.com/blackbox > > Right now I am leaning towards 2 (with the updates to fit the screen better). > > Please only mail this list, check those CC lists. > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: newbies ..
And, let me just say, nice job Luke! =:) I'd had bbconf in mind for the last year (didn't know there was a whiteBOX in the world) before I wrote it, and if it wasn't for xOr's help, bbconf would have taken MUCH longer than the month we took to crank out the first release. So, I definitely understand and appreciate the hard work you've put into your app. To be applauded, for sure!! =:) On Thu, 2002-01-24 at 20:26, Luke Freeman wrote: > > On Fri, 2002-01-25 at 11:56, Sean 'Shaleh' Perry wrote: > > > > Not to jab, but other than it being GTK based, why not use bbconf? > > > Well, if you are looking purely at the configuration aspects (menu/style > editors) of blackbox there is no real difference between bbconf and > whiteBOX. I think as a menu editor and style editor they are pretty much > evenly matched. > > bbconf does feature an excellent frontend for bbkeys, a feature which is > still under development for whiteBOX, but not currently included. So .. > maybe thats a reason to use bbconf. > > My main emphasis was to employ plugins which are bb specific first > (menu/style), and then start moving on to plugins which, whilst not bb > specific, allowed the user to customise their desktop. I had already > developed the background tool as a standalone earlier and decided it > could be useful in enhancing ones desktop (more easily). > > But, I suppose it really comes down to whether or not you like GTK or > QT, like you said. Personally I prefer GTK to QT purely because i like > the GTK LnF and I regularly have trouble compiling them on RedHat > (coincidence?). > > I think you should probably try both and decide for yourself. Variety is > generally always a good thing ... > > -luke > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: .blackboxrc keeps resetting the value of slit.onTop
That's what I was thinking too. Sean--wouldn't it be better if blackbox rewrote its rc-file if and only if and immediately after blackbox changed any of its config options? On Thu, 2002-01-24 at 08:11, Guido 'lenix' Boehm wrote: > "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> felt like writing: > > Um. This has never made sense to me. Is there any good reason that > > blackbox should overwrite its rc-file every time it exits? I really, > > really think this needs to be changed. At some point, I'm going to > > add a bbconf plugin that lets the user make changes to his/her > > blackbox rc-file. This will be an impossible task as long as > > blackbox insists on overwriting its rc-file at exit. > > > > Sean--are you open to changing this? Does anyone have a good reason > > why it shouldn't change? > > i believe the original reason why it was done this way was because > blackbox doesn't write out the rc-file immediatly after you changed > some config-option from the gui (ie adding a new workspace, change > workspace name, etc). at least, this is what i'm experiencing when > changing something, but maybe i'm wrong. > > > regards, lenix aka. guido > -- > www: http://www.lenix.de > fon: +49 - 173 - 80 99 196 > No, CTRL-ALT-DEL is not the proper way to end a programm. (RFC 1882) > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: .blackboxrc keeps resetting the value of slit.onTop
Um. This has never made sense to me. Is there any good reason that blackbox should overwrite its rc-file every time it exits? I really, really think this needs to be changed. At some point, I'm going to add a bbconf plugin that lets the user make changes to his/her blackbox rc-file. This will be an impossible task as long as blackbox insists on overwriting its rc-file at exit. Sean--are you open to changing this? Does anyone have a good reason why it shouldn't change? I understand the importance of blackbox trying to make sure it has a good rc-file for the next time it opens, but I think the current implementation of the solution for whatever problem this was trying to solve is incorrect. On Thu, 2002-01-24 at 01:35, Sean 'Shaleh' Perry wrote: > > blackbox writes out the rc file when it exits. The ONLY safe way to edit the > rc file is to exit blackbox, then edit, then restart blackbox. > > Note, blackbox will still maximize a window into the area the slit fills, it > will just be under the slit and not on top. > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: toolbar
I agree. The toolbar does serve a purpose--more than one actually. If anything, it (or some other blackbox-created window) needs to be there to catch KeyPress's if keyboard-navigable windows are going to be included in blackbox proper. And, I use the toolbar often for workspace-navigation, etc. On Mon, 2002-01-21 at 08:38, Eric Christian Carlsen wrote: > I wanted to place my vote for leaving the toolbar as compiled in by default. I > indirectly use it all of the time. What I mean by this is that when I have a > window maximized but not covering the toolbar it leaves me room on either side > of the toolbar to click on the screen and get the root menu. If a window were to > be maximized so as to occupy the entire screen it's a pain getting the root > window menu. Granted, most of us probably launch applications with bbkeys but > that isn't always the case. Just thought I'd make my opinion known since the > tide seems to be against the toolbar. > > Eric Carlsen > [EMAIL PROTECTED] > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Comments desired regarding possible upcoming changes
On Mon, 2002-01-21 at 10:41, Jan Schaumann wrote: > Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: > > > a) are there any OS/2 people out there using blackbox. I would like to remove > > the OS/2 cruft if possible. > > Never having used OS/2, I don't care either way, but it's an almost > philosphical question: should support for any Operating System be > dropped if the usernumber falls below a certain number? I guess since > OS/2's basically dead, it really doesn't matter. I vote for removing the cruft related to OS/2. The fact that I've not come across one person using OS/2 and blackbox--or having questions related to--in the 4+years *scratching head at how long it's been really since I first used Brad's blackbox with pixmap icons in #linux* that I've been using blackbox tells me there's not all that much interest in it anyway. =:) > > > b) the slit is currently a compile time option which I think is a little silly. > > How many of you actually compile with the slit turned off? How many of those > > would care if the slit was still in the code, but only active if an app was > > actually in it? In other words, why are you disabling the slit? > > At home I use the slit with one or two dockapps - at work I don't use > the slit at all, and even though I never recompiled bb to exclude the > slit (I would if I didn't use it at home, but can't as at work I don't > want to have a copy of BB separate from the systemwide install), I think > it's a good idea to have it be a compile-time option. > Um. I disagree. Having this as a compile-time option has always seemed silly to me. I think this should always be enabled. If you don't put anything there, it won't show up. If you use dock apps at all, then you need it to be there. It seems to me that it just complicates things going forward leaving it as a compile-time option--makes maintenance a more difficult task. > The Toolbar I only use for the date's advanced capabilities (strftime) > over bbdate. If the Toolbar could be a compile-time option[1], I'd leave > it out and adjust bbdate to support strftime and construct my own > Toolbar-lookalike from bbmail, bbdate and bbweather. > Um. I may be completely confused (quite possible--probability rather high considering nobody else has thought of this), but isn't this already possible by using the slit in a horizontal manner and docking the mentioned apps? It seems to me that you'd end up with a horizontal bar that looks and feels exactly like a custom-constructed toolbar. And I understand that the missing piece for you seems to be bbdate not doing strftime -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
bbkeys 0.8.4 and bbconf 1.4 released
blammo, etc. Okay, please READ this carefully In anticipation of shaleh releasing blackbox 0.62.0 tomorrow, I'm releasing bbkeys 0.8.4 into the wild blue yonder. You do not HAVE to have the latest and greatest blackbox (namely 0.62.0) to use this latest bbkeys, but 5 things won't fully work. =:) Namely, ToggleDecor, StickWindow, MaximizeWindow, MaximizeHorizontal, and MaximizeVertical will exhibit one-way functionality. In other words, the atom count for blackbox's attributes has changed in version 0.62.0. For these 5 functionalities, bbkeys will be able to set a window to the state you desire, but he will be unable to undo them by himself. This is only until you upgrade blackbox to 0.62.0. Conversely, if you upgrade to blackbox 0.62.0 and don't also upgrade to bbkeys 0.8.4, you'll see the same behavior. So, 0.8.4 bbkeys goes with blackbox 0.62.0. There, I think I've made it clear enough. Now onto the fun stuff... =:) I'm also releasing bbconf 1.4 tonight. There are lots of enhancements, bug fixes, and neato thingeys in both releases and I'll try to explain a little below Both apps sport ChangeLogs a mile long. So I'll paste them in-line and add comments as appropriate =;D First, from bbkeys --- version 0.8.4 -- - add a sanity check to the removeWindow function. Basically, blackbox tells bbkeys when a window disappears, or is removed. If the window being removed was the last window blackbox specified as having the input focus, bbkeys now resets what it thinks has the input focus. This prevents the bug reproducable by iconifying the last window on a workspace, and then trying to maximize "nothing". [xOr] - cleaning up build again. Rather than having 200 -DDEFINE_ statements in our compile lines, we use config.h (like normal people). =:) This very well may break stuff, but it looks good thus far [vanRijn] - adding AM_MAINTAINER_MODE to stop the ever-annoying "here, let me run aclocal for you again!!" idiocy of automake and friends [vanRijn] - fixing things for multi-head displays--replacing "getScreenInfo(0)->getRootWindow()," with "getCurrentScreenInfo()->getRootWindow()," So yes, bbkeys now has multi-head support. Sort of. You need to have a separate instance of bbkeys running against each head ("bbkeys -display :1"), etc. cat complaints >> /dev/null [vanRijn] - removing kludgy C command-line configurator with much-improved perl script from Damien Tougas (thanks!!!) [vanRijn] YAY to this!! bbkeysconf.pl is the new perl bbkeys configurator script. Look for it. Love it. =:) - changing bbkeys.cc to look for bbkeysconf.pl rather than bbkeysConfigC [vanRijn] - removing showAllWorkspaces from bbkeys.{bb,nobb} config file and making it an additional keybinding. This allows two different ways of showing all open windows and navigating through them--one keybinding for the regular "NextWindow" variety (as in previous versions of bbkeys, and another keybinding, "NextWindowAllWorkspaces", that pops up the window list for navigation for windows open on all workspaces. [vanRijn] - bugfix previously, bbkeys would ignore windows that had no name. We now follow blackbox's lead (and follow blackbox's code) and create a name for it, "Unnamed". Thanks to Damien Terrier for this bug report. [vanRijn] - patch for allowing an alternate keybinding config file (thanks to Scott Moynes!) [vanRijn] - sync with blackbox for 0.62.0--attributes element Atom has changed to now include decoration state so that ToggleDecor() works. [vanRijn] - including patch from Sergey Vlasov for allowing use of Meta and Hyper modifiers, also try to get the correct Num_Lock and Scroll_Lock modifier mask from the X server rather than hard-coded. I've not had tons of time to play with this, though I have made sure that it works on my laptop. =:) [vanRijn] - fix for RPM-building process... install gzipped man pages by default on RPM-based systems. Thanks to Darryll for the bug report!! =:) [vanRijn] - removing bbkeysconf and bbkeysConfigGtk *shudder* apps from chain-launching mode. These babies are dead and let's just move on folks By keeping them in there, I'm afraid people will think it's okay to use them. It's not. They're WAY out of date. Also, thanks to a smarter way of handling key grabbing configuration in bbconf, we don't have to hang bbkeys while keygrabs are being configured. [vanRijn] - adding logic to bbkeys to pass configurators correct command-line arguments so we load the rc-file that our user is running bbkeys with. [vanRijn] - long-overdue documentation finessing, thanks to Roman Neuhauser for the patches and suggestions! =:) Also, adding CVS version id's to all source and documentation files, woot! =:)
Re: Threads BB Web - Reworked
I cast my vote on this one also. Great work, Thread! =:) On Wed, 2002-01-09 at 19:28, scott wrote: > ray@crytek wrote: > > > I've tested on w3m, IE6 (win2k) and Mozilla (win2k). This is really Thread's > > design cut back, thats all > > > > Oh yer, the URL :] > > http://www.planetquake.com/lvl/blackbox/ > > > This is where my vote goes... i like threads' design, > especially stripped down. :) > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys questions/comments
=:D On Tue, 2002-01-08 at 17:07, Jamin W. Collins wrote: > On Tue, 2002-01-08 at 15:59, Jason 'vanRijn' Kasper wrote: > > Look on http://movingparts.net/bbkeys_archived.shtml and search for > > "windows". =:) > > As usual, you and xOr rock. Thanks for the advice. > > Jamin W. Collins > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: BB Feature
Actually, with the soon-to-be-released-but-currently-available-via-CVS 0.8.4 version of bbkeys, this is a separate keybinding. So, you can have for NextWindow and for NextWindowAllWorkspaces. This has been removed from the bbkeys.bb config file that xOr mentioned below in version 0.8.4. On Tue, 2002-01-08 at 16:45, xOr wrote: > On Tue, Jan 08, 2002 at 02:12:39AM +0100, Mark Weinem wrote: > > On Mon, 07 Jan 2002, xOr wrote: > > > > > You can set up bbkeys to show the windows on all workspaces in its > > > list. So then when you hit alt-tab (or whatever you want) and get a > > > list of all windows and just release th emodifier key (alt in this > > > case) to switch to the window of your choice. > > > > How do i set this up? I only get a menu that shows the windows of the > > *current* workspace. If i change to an empty workspace there's no menu > > available. > > > > FreeBSD 4.4 + XFree86 3.3.6 > > blackbox 0.61.1 (ports) > > bbkeys 0.8.3(ports) > > in your ~/.bbtools/bbkeys.bb or /usr/share/bbtools/bbkeys.bb > > ! set this to true to allow stacked cycling to go to any window on any > ! workspace. all of the windows will appear in the menu if it is being shown. > !bbkeys.menu.showAllWorkspaces: True > > xOr > -- > I am damn unsatisfied to be killed in this way. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys questions/comments
Look on http://movingparts.net/bbkeys_archived.shtml and search for "windows". =:) On Tue, 2002-01-08 at 15:59, Jamin W. Collins wrote: > On Mon, 2002-01-07 at 18:38, Imad wrote: > > > The best way is to run xev and see what X calls your > > > keys. Then, you just put the key (XLookupString gives 1 characters: > > > "f"), etc. in your ~/.bbkeysrc as shown in the README. > > > > That's what I tried, but I kept getting "XLookupString gives 0 > > characters: ""). I went back to try it again after getting your message, > > and noticed that right after the keycode there's a bit that reads > > "(keysym 0xffe7, SunFront)" (this is also how xev treats > > Mod/CTRL/Shift). D'oh! I put "SunFront" as the KeyToGrab in bbkeysrc and > > everything's working fine. > > Since we're talking about key-bindings, how would I go about using keys > that xev displays no character or keysym for? All the "windows" keys on > my keyboard return only a differing keycode. There is no keysym for > them and certainly no character. On a few other keyboards, I have extra > buttons that likewise don't return keysyms or characters. > > Any ideas, or are they just dead keys? > > Jamin W. Collins > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Blackbox Web Design
WOW! This I REALLY like, Thread! =:) And I'm ECSTATIC to read that we've finally come up with a "fix for the door whack monkey glitch in the centralcome out and fling small things into people's eyes" YAROOH!!! =:) LOL Seriously, I dig this design heavily. I may have to, um, borrow it for myself... =:) On Mon, 2002-01-07 at 22:03, Thread wrote: > Wacha guys think of this? > > http://www.threadbox.net/blackbox > > We can add some more cutie graphics if that's what people like, but I > also know the blackbox crowd is a minimalistic one. (I know I am.) We'll > see what people like. > > -Thread > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys questions/comments
On Mon, 2002-01-07 at 19:38, Imad wrote: > > Thanks for the help, and for bbkeys! > Thanks for the thanks!! =:) > Best, > > --Imad "(e)magius" Hussain > _ > "There is much to be known and above all, much to be loved... Indeed, > the more we find to love, the more we add to the measure of our hearts." > > -- Lloyd Alexander (via Adaon), _The Black Cauldron_ > __ > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys questions/comments
On Mon, 2002-01-07 at 19:07, Imad wrote: > Doubtless this is slightly off-topic, as this is a BlackBox mailing > list, not a bbkeys ml, but as the two programs are rather close... well, > let's just leave it at that. > > I've got a couple querries/comments on bbkeys: > > 1) I'm not a real QT-kinda person, but I have many non-standard keys on > my keyboard (it's a Sun 5 thingy) like Stop, Again, <>, Front, Open, > etc. that I'd like to use with bbkeys. How do I know what bbkeys refers > to these keys as? I can get the numeric representations of these keys, > of course, but what do I put in .bbkeysrc? > QT-kinda person? The best way is to run xev and see what X calls your keys. Then, you just put the key (XLookupString gives 1 characters: "f"), etc. in your ~/.bbkeysrc as shown in the README. > 2) Is there any way to open/close the various menus (Workspaces/Icons, > Main) through bbkeys? Such a feature would be rather nice. Then again, > in BlackBox, you can't navigate menus with the keyboard anyway, so this > would only be of benefit to people who use full maximization (like yours > truly). > No. Hopefully in blackbox 0.70. =:) > Best, > > --Imad "(e)magius" Hussain > _ > "There is much to be known and above all, much to be loved... Indeed, > the more we find to love, the more we add to the measure of our hearts." > > -- Lloyd Alexander (via Adaon), _The Black Cauldron_ > __ > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Bug in Blackbox 0.61.1 with blackbox 0.61.1 icon patch V9
That's because you're using "XGetInputFocus(display, &w, &revert);" every time you do something with a window. bbkeys uses a ClientMessage from blackbox to know what the currently focus'd window is. This was done by design as an example of correct ICCM interaction, etc., etc. * [01/06/02 22:24] Of all the gin joints in all the towns in all the world, * Scott Moynes <[EMAIL PROTECTED]> walks into mine and says: > * Milan Roubal ([EMAIL PROTECTED]) wrote: > > Hi, > > I am using bbkeys, when I pressed keys for maximilization of window, it is all >right. > > But when I make icon from any window and then press keys for maximilization of > > window, window maximizes and X restart and I need to login back. > > in log is: > > /usr/local/bin/blackbox: signal 11 caught > > shutting down > > aborting... dumping core > > X connection to :0.0 broken. > > > This is where the plot thickens. Using epistrophy, with basically the > same code, I get no such crash. > > -- > scott -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Bug in Blackbox 0.61.1 with blackbox 0.61.1 icon patch V9
* [01/06/02 21:23] Of all the gin joints in all the towns in all the world, * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> walks into mine and says: > > On 07-Jan-2002 Jason 'vanRijn' Kasper wrote: > > Hm thrice. The problem here is that blackbox is trying to perform a > > maximize operation on a window that's not visible. I believe that the > > correct fix is to add a simple check to the top of > > BlackboxWindow::maximize to see whether the window we're performing this > > operation on is even visible. > > > > It's a one-liner fix, so I don't think a patch is necessary. But my > > suggestion is to add "if (!flags.visible) return;" to the top of this > > function. In the 62.0pre2 source of Window.cc, at line 1485, change > > > > void BlackboxWindow::maximize(unsigned int button) { > > > > to > > > > void BlackboxWindow::maximize(unsigned int button) { > > if (!flags.visible) return; > > > > > > Any thoughts contrary to this? > > > > Let me get this straight. You have Window A focused. You click the iconify > button. It goes away to icon land. You then hit alt+m (or whatever you have > as MaximizeWindow) and blackbox crashes because it tries to maximize the window > it just iconifed? It sounds to me like the real problem is blackbox is using > the wrong window as the recipient of messages. Or did I misunderstand? > If blackbox doesn't set focus on a window other than the one it just minimized, than the now-iconified window still is marked as being the current window. Note--this problem only occurs when blackbox minimizes a window and doesn't have another window to set focus on. bbkeys isn't given a different "currently focused" window to operate on, so it tells blackbox to perform whatever operation (in this case maximize) on the now-iconified window. It's an obscure bug, but I think blackbox should be doing a sanity check (especially such a simple one as this). -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Bug in Blackbox 0.61.1 with blackbox 0.61.1 icon patch V9
Hm thrice. The problem here is that blackbox is trying to perform a maximize operation on a window that's not visible. I believe that the correct fix is to add a simple check to the top of BlackboxWindow::maximize to see whether the window we're performing this operation on is even visible. It's a one-liner fix, so I don't think a patch is necessary. But my suggestion is to add "if (!flags.visible) return;" to the top of this function. In the 62.0pre2 source of Window.cc, at line 1485, change void BlackboxWindow::maximize(unsigned int button) { to void BlackboxWindow::maximize(unsigned int button) { if (!flags.visible) return; Any thoughts contrary to this? On Sun, 2002-01-06 at 20:22, Milan Roubal wrote: > Hi, > I am using bbkeys, when I pressed keys for maximilization of window, it is all right. > But when I make icon from any window and then press keys for maximilization of > window, window maximizes and X restart and I need to login back. > in log is: > /usr/local/bin/blackbox: signal 11 caught > shutting down > aborting... dumping core > X connection to :0.0 broken. > . >Milan Roubal >[EMAIL PROTECTED] > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Bug in Blackbox 0.61.1 with blackbox 0.61.1 icon patch V9
Hm again. Good news and bad news... Good news is that this bug exists in blackbox 61.1 proper. Bad news is that this bug exists in blackbox 61.1 proper. =:\ On Sun, 2002-01-06 at 20:22, Milan Roubal wrote: > Hi, > I am using bbkeys, when I pressed keys for maximilization of window, it is all right. > But when I make icon from any window and then press keys for maximilization of > window, window maximizes and X restart and I need to login back. > in log is: > /usr/local/bin/blackbox: signal 11 caught > shutting down > aborting... dumping core > X connection to :0.0 broken. > . >Milan Roubal >[EMAIL PROTECTED] > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Bug in Blackbox 0.61.1 with blackbox 0.61.1 icon patch V9
Hm. I can confirm this. Iconize a window, then immediately do a keybinding that tells blackbox to maximize a window. Core dump. Backtrace below, running 62.0pre2 (gdb) bt #0 0x401c5911 in kill () from /lib/libc.so.6 #1 0x401c55f4 in raise () from /lib/libc.so.6 #2 0x401c6d71 in abort () from /lib/libc.so.6 #3 0x0804b1c5 in signalhandler (sig=11) at BaseDisplay.cc:164 #4 0x401c5848 in sigaction () from /lib/libc.so.6 #5 0x08063026 in BlackboxWindow::maximize (this=0x809c9a8, button=2) at Window.cc:1598 #6 0x080658b0 in BlackboxWindow::changeBlackboxHints (this=0x809c9a8, net=0xbfffe418) at Window.cc:2877 #7 0x08068e70 in Blackbox::process_event (this=0xbfffe61c, e=0xbfffe57c) at blackbox.cc:677 #8 0x0804b9e2 in BaseDisplay::eventLoop (this=0xbfffe61c) at BaseDisplay.cc:382 #9 0x0806c6e1 in main (argc=1, argv=0xb684) at main.cc:168 #10 0x401b565f in __libc_start_main () from /lib/libc.so.6 First one to come up with a patch gets a doggie biscuit! On Sun, 2002-01-06 at 20:22, Milan Roubal wrote: > Hi, > I am using bbkeys, when I pressed keys for maximilization of window, it is all right. > But when I make icon from any window and then press keys for maximilization of > window, window maximizes and X restart and I need to login back. > in log is: > /usr/local/bin/blackbox: signal 11 caught > shutting down > aborting... dumping core > X connection to :0.0 broken. > . >Milan Roubal >[EMAIL PROTECTED] > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: (forw) [syngin@gimp.org: More stuff]
Actually, this is fixed in the CVS version of bbkeys. Thanks to Sergey Vlasov for the original bug report and fix patch. =:) All who care, please pull down the CVS version of bbkeys and give this a try. (http://movingparts.net/bbkeys.shtml has the link for how to get CVS access) On Thu, 2001-12-20 at 09:42, xOr wrote: > On Thu, Dec 20, 2001 at 10:35:25PM +1030, Tim Riley wrote: > > When cycling though windows everything seems to go alright until I get go of > > the modifier key (Mod4). With Mod4 (in my case, the evil Windoze key), the > > popup that displays the currently selected window that is being focused will > > not "drop". It stays locked in focus and I have to press ENTER to give focus > > to the window. If I use Mod1 (ALT in my case) it works fine. Any ideas? It > > worked fine while I was stuck with Sawfish. > > I'll look into this when I get the chance in the next few days. > > xOr > -- > I am damn unsatisfied to be killed in this way. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: free food and bbkeys
Um. Just out of curiosity, what exactly are you referring to with "will we cater to every problem bbkeys has"? I'm the author of bbkeys and I've always worked (with very little thanks) to make sure there are no problems with bbkeys. Perhaps a little clarification? On Sat, 2001-12-15 at 00:51, Seann Alexander wrote: > Are there people out there who don't use bbkeys, and particulary don't care > if bbkeys happens to hang things? Like will we cater to every problem bbkeys > has, unless its a strickly non-bbkeys problem? > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Blackbox allows several instances of Opera.
Actually, this happens with netscape as well. If you pass netscape the -remote parameter so that it doesn't think it has to start a session from scratch, and netscape is on a different workspace, you'll hit the same problem. I do not believe it has anything to do with opera not doing things right. I believe the error is how blackbox handles windows (XChangeProperty to withdrawn state via setState() ) when it switches workspaces. I think that sets the window into a state that causes it to not received calls that it otherwise would. On Wed, 2001-12-12 at 17:37, Christian Dysthe wrote: > On 12 Dec 2001 14:32:15 -0500 > "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> wrote: > > > I believe that I've fixed this, actually. WOOT. > > Does this mean that this is not really an Opera issue, or something > that Opera should fix? > > -- > Christian Dysthe > http://www.dysthe.net > ICQ: 3945810 > Registered Linux User #228949 > > "Everybody ought to have a Lower East Side >in their life" > > -Irving Berlin- > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Blackbox allows several instances of Opera.
Actually, wmaker's code looks like this /* prevent window withdrawal when getting UnmapNotify */ XSelectInput(dpy, wwin->client_win, wwin->event_mask & ~StructureNotifyMask); XUnmapWindow(dpy, wwin->client_win); XSelectInput(dpy, wwin->client_win, wwin->event_mask); XUnmapWindow(dpy, wwin->frame->core->window); .. , whereas blackbox's code is this .. XUnmapWindow(display, frame.window); XSelectInput(display, client.window, NoEventMask); XUnmapWindow(display, client.window); XSelectInput(display, client.window, PropertyChangeMask | StructureNotifyMask | FocusChangeMask); Slightly different. I've not had a chance to look at what exactly the difference in results is =:) On Wed, 2001-12-12 at 14:41, Sean 'Shaleh' Perry wrote: > > > > Shaleh, please take a gander at this and see if you have any objections > > to putting it in 61.2. The affect that this has (at least with this > > opera situation) is that opera's state hasn't changed to Withdrawn and > > he's now able to receive the "open a new link" message. Now, granted, > > opera doesn't magically switch the desktop to where it is, but it does > > get the message to open a new link and doesn't open a brand new window > > on the current desktop > > > > So, again, the fix that I've come up with is as follows Window.cc > > should have this > > > > Window maker's code look just like yours vanR. I would like to know if Brad > had a reason for the state call. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Blackbox allows several instances of Opera.
I believe that I've fixed this, actually. WOOT. This has annoyed me to no end. The problem as I see it is that blackbox sets the window state for any window not currently on the current workspace to "withdrawn". I believe this causes opera to behave differently and not know that it already has a window open. If you comment out line 1428 (in my blackbox source anyway) of Window.cc, in BlackboxWindow::withdraw(void) where he does setState(WithdrawnState);, it should fix this. Brad, if you're reading is there any reason that this was put in? Simply XUnmapWindow'ing windows that aren't on the current workspace seems to work fine. Shaleh, please take a gander at this and see if you have any objections to putting it in 61.2. The affect that this has (at least with this opera situation) is that opera's state hasn't changed to Withdrawn and he's now able to receive the "open a new link" message. Now, granted, opera doesn't magically switch the desktop to where it is, but it does get the message to open a new link and doesn't open a brand new window on the current desktop So, again, the fix that I've come up with is as follows Window.cc should have this void BlackboxWindow::withdraw(void) { visible = False; iconic = False; // setState(WithdrawnState); XUnmapWindow(display, frame.window); XSelectInput(display, client.window, NoEventMask); XUnmapWindow(display, client.window); XSelectInput(display, client.window, PropertyChangeMask | StructureNotifyMask | FocusChangeMask); if (windowmenu) windowmenu->hide(); } On Wed, 2001-12-12 at 11:33, Sean 'Shaleh' Perry wrote: > On 12-Dec-2001 Christian Dysthe wrote: > > Hi, > > > > I asked about this a while back, but got no answer. Maybe someone > > now knows why Blackbox allows several instanses of Opera (the web > > browser) as long as each instance is opened on different desktops? > > > > For instance, if I click on a link in my mailer an Opera instance is > > opened even though another instance of Opera is running on another > > desktop. In other WM's a click on an e-mail link switches to the > > desktop where Opera is already running opening a window with the > > link content, while in Blackbox one is opened on the current > > desktop. > > > > I know for a fact that Opera is not designed to allow several > > instances of itself. So why is Blackbox allowing it for this > > application while other WM's I have tried this on (KDE, Gnome, IceWM > > and XFce) don't? > > > > That is not the wm's job. If the app wants to only allow one instance it can > handle that. Switching workspaces (desktops) is even worse behaviour. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Upcoming 0.61.2 realease (was: call for patches)
There's a flaw in LinkedList also xOr talked with Raven on July 28th about this one Pasting from his e-mail I've found a problem in LinkedList.cc: check out line 164: __llist_node *nnode = new __llist_node, *inode = _first->getNext(); how this function works is, if 0 is passed in as the index to insert to, then the new item is added at the top of the list. So, the highest in the list one can insert after the top is, of course, at index 1. The above line sets inode to _first->getNext, the _second_ element in the linked list. If an index of 1 is passed in, then inode is not modified and the new node is added after inode. This makes the new node go into index 2, not index 1. A simple fix for this is to change line 164 to: __llist_node *nnode = new __llist_node, *inode = _first; This probly affects most of the bbtools and maybe blackbox itself.. as all insertions into the linked list have been at (index+1). On Tue, 2001-12-11 at 11:54, Sean 'Shaleh' Perry wrote: > > Changes from 0.61.1 to 0.61.2: > - added the ja_JP nls directory > - general code cleanups > - blackbox-nls.hh is always generated even if --disable-nls is used. > This allows us to not have all of those hideous #ifdef NLS chunks. > Nothing to worry about, if you do not want NLS this does not affect you > - Workspace::placeWindow() cleanups. Also a speed bump from reducing the > use of iterator->current() and changing the delta from 1 to 8 > - cleanups to compile with g++ 3.0 > - make distclean actually removes Translation.m and blackbox-nls.hh > - fixed a desciptor leak in BScreen::parseMenuFile, seems opendir > lacked a matching closedir. > > Is my current changelog. If anything in that list is not clear, please speak > up. If something should be in that list, also speak up. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: On the matter of the next bb release
* [11/25/01 23:45] Of all the gin joints in all the towns in all the world, * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> walks into mine and says: > My goals for blackbox are as follows: > > infrastructure: > have a current and updating website > a bug tracker so that we do not rely on the memory of this mailing list Definitely a good idea. I'd like to add to that list a publicly accessible CVS repository, ideally with a cvsweb-cgi front end or what have you. > a place for patches that are waiting to be applied > > code: > once we know the current bugs we need to decide which of them can be fixed and > which of them require a redesign or rewrite. Ones that can be fixed will. I > suspect bb will fork and there will be the tried and true one we have now, > slowly having its holes plugged as well as a development branch. > Shaleh, I don't rememeber if you were in the channel when we had this same discussion in #blackbox, but kyle and myself and a few others have started a pretty comprehensive list of things that NEED to be done for a stable, updated blackbox. I send this to the list because most of the people in #blackbox have long-since unsubscribed from this mailing list. Please check with kyle in #blackbox, as he's the current keeper of the list =:) > Currently there is myself and two others involved. We all have been here a > long time and believe in the current blackbox approach. You will not see lots > of crazy new features. let waimea and fluxbox handle that. Amen and hallelujah. Please include me in the list of interested parties and need-to-know-during-code-writing's, since internal changes to blackbox will affect bbkeys as well as all of Kennis's bbtools. > > As soon as the todo list is more substantial the people on this list become > aware of it. See above. =:) -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys configuration [was: Re: iconized bbkeys]
On Thursday 15 November 2001 14:36, Scott Moynes wrote: > * Roman Neuhauser ([EMAIL PROTECTED]) wrote: > > To answer my own question, and so that it's archived: > > the keymap file (.bbkeysrc) is not the same as the style file > > (bbtools/bbkeys.bb). Looks like the -c switch is meant for the latter > > one, and bbkeys doesn't respond to any mapped keypresses if you point > > it at .bbkeysrc with -c. > > A few days ago I created just such a patch, and should be in the > mailing list archives by now. It has been accepted for inclusion in > the next release of bbkeys which, from what I hear, should happen any > day now. If you can't wait, it's in the CVS tree, which seems to be > pretty stable right now, so feel free to grab the newest tree. As Scott said above, this has been included in bbkeys-0.8.4. BBkeys will now allow command-line configurability of where its look-and-feel config file comes from as well as where its keybindings config file comes from. I'm not quite done with what I want in there for 0.8.4 yet, so if you're so inclined, please pull bbkeys down from CVS and give it a whirl. One thing to be noted, though, is that this will most probably cause some issues down the road when blackbox has rudimentary keybindings built into it, as blackbox proper will by default look in ~/.bbkeysrc for its own limited keybindings. > > > There is one glitch I can see: currently, bbkeysconf and the like > > don't have to look where the actual keymap file resides: it's hardcoded > > as ~/.bbkeysrc. This could be solved like this: the path to the keymap > > file would be specified in the style file, and bbkeysconf would look for > > it there. If the style file doesn't contain the directive, just dump it > > to the standard place. > > vanRijn, the author of bbkeys, told me he was in the process of > changing that. However, I don't think it will be changed in > bbkeysconf. I think that configurator has been superceded by bbconf; > look for the changes there. Um. There's no way I want to even think about putting bbkeys.conffile: into style files. bbkeys will look for its keybindings in two places: either you tell it otherwise in the command line with "-rc " or it looks in ~/.bbkeysrc. Either way, if it can't open it, you'll hear about it in STDERR. Also, bbkeysconf (the QT bbkeys-only configurator) has been dropped from my list of things I care about. It's dead. So is bbkeysConfigGtk. So is bbkeysConfigC, thank God. Going forward from the 0.8.4 release of bbkeys, bbkeys will have a very nifty perl script (correctly auto-detected of course), thanks to Damien Tougas, that does a MUCH better job of interactively configuring your bbkeys file. And the bbconf plugin for blackbox keybindings will also be kept up-to-date with these changes as well. And you're right--bbkeysconf.pl and bbconf will have to have some smarts added for "open another file" and "save as" for its settings. > > > Oh, the bbkeys docs are full of stuff like "the other config file". > > As you might have noticed, changing the terminology to "keymap file" and > > "style file" could help get rid of this confusion. > > This, perhaps, is the reason why the newest release of bbkeys hasn't > hit the press yet. Feel free to modify the docs if you like, and > submit the changes. I'm sure every developer would like to see the > contribution of documentation. :) > > scott Actually, it's other reasons, but by ALL means, I'd love patches to the man-pages and documentation. Hell, just send me the new files and I'll pull them in, most probably. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbappconf
On Wed, 2001-11-14 at 11:55, Derek Cunningham wrote: > > Okay. Yes, you're absolutely right. And this is a blackbox issue. > > Blackbox is broke WRT windows that have decorations removed from them. > > and yet there are some people on this list that feel that blackbox is fine > as is. Sure, this is an eye-candy issue... but still, it's a bug, period. Agreed. And henceforth and thusly, said bug should be squashed. > > > I've added code to bbkeys to allow decoration toggling (toggleDecor, > > which will add or strip decorations from the currently-focused window) > > and went as far as I can go. > > ok... is this a patch to bbkeys, or is it in the main distro? how do I > utilize this function? The functionality is built into bbkeys 0.8.x. It just doesn't work because blackbox is broke in this regard. > > Blackbox's internals are broken also with > > regards to being able to tell other apps what the decoration state of a > > given window is. > > where is this functionality useful? > Well, for instance, this one. =:) I'd like to at-will take all window decorations off of a window (a decor-less, sticky aterm would suit me nicely, thank you), and then be able to add the titlebar/buttons, etc. back on when I want also. > > I've patched blackbox to at least tell external > > applications whether a given window is decorated or not, but it really > > does no good because there's the other problem in which blackbox acts > > like it's going to let you move or resize a now-undecorated window, but > > doesn't really do it. > > > > another bug. see above statement! see above answer. Bottom line--it's broke and should be fixed. > > > I've approached Raven (who responded to me, but it's been so long I > > forget what was said) > > of course, you archive your email, correct? :) so you could easily load up > your personal archives, to find out what's up. :) `man hard_drive_crash && man month_old_backup` > > > and nyz (who said that the version of KDE that he > > runs doesn't have that issue =:) ) about this and it never went > > anywhere. > > haha... so basically, in short, nyz has given up on bb? nyz (Brad Hughes) works for trolltech, lucky bugger that he is. And as such, it's most probably more advantageous for him to use a window manager that is directly affected by the work that he does, namely with qt. > > > > > So, Jeff, if you're out there, is there any update on where this falls > > on the official blackbox TODO list? > > > > better question: IS THERE a todo list? and is there any update at all WRT > blackbox development? > *listening very intently for answer myself* -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbappconf
On Wed, 2001-11-14 at 09:20, Derek Cunningham wrote: > ok... to clarify: bbappconf removed all the window decorations (including > title bar). Now, having done this, I fully expected to have to alt-click to > move my windows, since that's what I had to do with Eterm when it was > borderless, but this doesn't work. > > when bbappconf removes the window decorations on aterm, alt+click doesn't > work... and I want to know why... this is utterly annoying! Okay. Yes, you're absolutely right. And this is a blackbox issue. Blackbox is broke WRT windows that have decorations removed from them. I've added code to bbkeys to allow decoration toggling (toggleDecor, which will add or strip decorations from the currently-focused window) and went as far as I can go. Blackbox's internals are broken also with regards to being able to tell other apps what the decoration state of a given window is. I've patched blackbox to at least tell external applications whether a given window is decorated or not, but it really does no good because there's the other problem in which blackbox acts like it's going to let you move or resize a now-undecorated window, but doesn't really do it. I've approached Raven (who responded to me, but it's been so long I forget what was said) and nyz (who said that the version of KDE that he runs doesn't have that issue =:) ) about this and it never went anywhere. So, Jeff, if you're out there, is there any update on where this falls on the official blackbox TODO list? -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
[Fwd: chained keygrabs]
Umm. Broken internals Heh. Basically, to do this cleanly, I'd have to do a major overhaul of bbkeys's internals. Not so much because they're broken now as much as the paradigm for how bbkeys operates would COMPLETELY change, not to mention a radical departure from what morel was working on as far as implementing rudimentary keybinding support in blackbox proper. There's no way I'd want to do something like this if it's not done right. And by "right" I mean in a manner that is consistent throughout bbkeys itself as well as the configuration tools, and cleanly coded, easy to maintain and follow. More than anything, I'm curious if anyone else has the desire/need for this kind of functionality. If I understand it correctly, this is leaning towards the Emacs model of keybindings that allow "chaining" things. So, you press and then press to do something. I would like to get some feedback from the blackbox user community on this--both interest in this sort of functionality as well as comments against it (if there's any). Thanks in advance, vanRijn -Forwarded Message- From: Scott Moynes <[EMAIL PROTECTED]> To: BlackBox Mailing List <[EMAIL PROTECTED]> Subject: chained keygrabs Date: 13 Nov 2001 02:21:23 -0500 Here is a patch to allow rudimentary support for chained keygrabbing. It allows you to specify one global prefix which must preceed any other keybinding. For example: KeyToGrab(m), WithModifier(Control), WithAction(Prefix) KeyToGrab(a), WithModifier(Control), WithAction(ExecCommand),DoThis(aterm) would allow you to hit Ctrl-m and then Ctrl-a to start aterm. Proper chaining will not be complete untill some of the broken internals of bbkeys are fixed. It is against the current CVS codebase. If there is any interest, I'd be persuaded to create a proper patch file. -- Copyleft (c) 2001, Scott Moynes
Re: bbconf
Okay, piece of crap balsa crashed on me, so this one's going to be even shorter. Check to see if $HOME/.bbtools/ exists. And to see if the directory is writable for the user running bbconf. And to see if $HOME/.bbtools/bbconf.bb is writable for the user running bbconf. On 2001.11.10 10:32 Christian Dysthe wrote: > On Sat, 10 Nov 2001 10:13:20 + > Kyle Donaldson <[EMAIL PROTECTED]> wrote: > > | > |To get bbconf to save it's settings, create the directory .bbtools under > |your $HOME directory. Then bbonf will save it's settings in > |~/.bbtools/bbconf.bb > > I guess I wasn't precise in my first mail. I do get bbconf to save most > stuff, but not the Qt stuff: The BBConf Qt Widget Style. When I try to > change that I get an error message saying it was not able to save to the > file specified, and I have not specified any file for this setting, and I > do not know how to. Not that it is important to me to change the widget > look and feel of bbconf, but still... :) > | > |--gile > | > > > -- > Kind Regards, > Christian Dysthe. > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: fluxbox, blackbox
You know, it's painful to even follow this discussion. Reading of one's hard work as being described as viral... Yes, I'm sure that's what I had in mind 2+ years ago. Let's go back a ways bbkeys is written on top of the extremely well-done code-base of the bbtools, written quite thanklessly by John Kennis. You know, bbpager, bbapm, bb*. They all started with John. And John deserves MUCH praise and thanks that I doubt he gets. Now, all of the bbtools use base classes from blackbox itself, and if you'll peruse through the code of bbpager, say, you'll note that the licensing throughout is as follows Anything that's coming from blackbox has the "noble" (God, that's an annoying adjective for something that is most of the time an afterthought when writing code in the hope that other people will find it useful) BSD-style license. Anything that John Kennis wrote is written under the GPL-2 license. Along comes bbkeys, based on bbtools. For starters, I believe it's appropriate that bbkeys carries forward the license of the code that it's based on, namely Kennis's bbtools. Let's call that reason 1 for the GPL "viral" license present in bbkeys. Now, if you'll actually read through the code in bbkeys.cc, you'll note that some parts of the code are derived from the work done in 2 other projects, namely XEmacs and WindowMaker. If you look closely, you'll notice that the original code that was used from those projects was licensed under the GPL-2. And the licensing for those pieces of code are included in bbkeys. We'll call that reason #2 for the GPL "viral" license present in bbkeys. Now, furthermore, and this is what's so very irritating about this entire discussion, other than the above 2 reasons, I gave about 3 seconds of thought to the issue of licensing at all. As I said before, most people who write code out of the goodness of their heart--in the hope that other people will find it useful--are NOT even thinking about what license and copyright they should slap on their code. Honestly. Is this the 8th deadly sin of mankind? Possibly. But really, people who enjoy coding in the attempt to try to help others are in my experience not the same people who love to haggle over copyright law and licensing issues. Furthermore (and I can see your eyes glazing over so I'll cut this short), as far as blackbox and bbkeys playing together... As I said before, I included the GPL-2 licensing with bbkeys because in my very limited knowledge about this sort of thing, it seemed like the Right Thing To Do (TM), based on the above facts. I have no qualm whatsoever about Raven including parts of bbkeys into blackbox proper. Hell, I'd love to see anything kick-start blackbox development again, just-married syndrome or not. If somebody wiser than I about the black arts of copyright issues can advise me on whether or not it's possible/legal/beneficial to replace the GPL-2 "viral" license in bbkeys with something more friendly to the world, so be it. You have my e-mail address. And in closing, bah humbug. On 2001.11.09 18:51 Jeremy C. Reed wrote: > On Fri, 9 Nov 2001, Scott Moynes wrote: > > > On that note, I see that bbkeys is viral GPL'd and our great blackbox is > using the noble BSD-style license. As it is, bbkeys can not (should not) > go back into blackbox. (Which is sad -- because I like bbkeys > functionality, but I prefer it to be part of blackbox.) > > Jeremy C. Reed > ... > ISP-FAQ.com -- find answers to your questions > http://www.isp-faq.com/ > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: fluxbox, blackbox
On 2001.11.09 12:44 Scott Moynes wrote: > > Blackbox used to include keyboard binding support, but it was pretty > poor and would be more maintainable in a separate app. So, in short, > fluxbox is the devolution of blackbox. This I completely agree with. Not to mention the fact that bbkeys is still in active development and enhancements. And why it was chosen to swallow an immediately out-of-date bbkeys into fluxbox rather than allowing it to remain a standalone app is beyond me. You've just complicated things rather than simplified them--blackbox and fluxbox could very easily have co-existed with bbkeys, and both would benefit from the separation of function. If keybindings had been left to bbkeys, fluxbox would have been a consideration for me. As it stands now, unless the fluxbox author intends to keep up with the still-{evolving,improving} bbkeys, or he removes keybindings from fluxbox, I have no interest in playing with it. -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: BB newbie questions.
Umm. I'm not sure I agree with your statement, but that's beside the point. There's no way that fluxbox will ever make its way into blackbox. On 2001.11.08 23:07 Christian Dysthe wrote: > Hi, > > I have Fluxbox running now. This is what BB would have been if it had > been actively developed. I like it. I would like to know if we are going > to see two parallel projects here, or if actually Fluxbox is going to end > up becoming the continuation of Blackbox. > > And I guess Fluxbox will be off topic on this list? :) > > On Wed, 07 Nov 2001 23:01:21 -0800 > Justin Rebelo <[EMAIL PROTECTED]> wrote: > > |Blackbox is not being currently developed. It doesn't need much work, > |though, anyways. However, some people have picked up the code and > |started a new project called "Fluxbox" with it. I know how stubborn bb > |users are (since I am one), but this really is a cool project. It's > |identical to current version of BB but with extra features added, such > |as having bbkeys built in so that you dont have to run a second app to > |manage keybinds. Also, the application tabs are awesome. I would not > |accept them at first because I am so conservative with my WMs, but this > |stuff is really great, it helps alot for keeping things minimal. Alot of > > |screenshots make flux look ass ugly, but thats just coincidence. You can > > |compare them on my desktop screenshots running the same theme, one in bb > > |and one in flux. Check em out at > | > |http://www.rebelo.ca/fluxbox/ > | > |You can get flux and more info from fluxbox.sourceforge.net. > | > |And no, I am not a developer plugging my own app, I am just a user who > |really thinks you guys should check this out. > | > |Justin Rebelo > | > |Mark Hill wrote: > | > |>On Wed, Nov 07, 2001 at 11:02:23PM -0600, Christian Dysthe wrote: > |> > |>>Hi, > |>> > |>>I am fairly new to BB and the documentation on the BB site isn't very > helpful. Lots of dead links. Is Blackbox out of development, or is it a > new site somewhere that I am not aware of? > |>> > |>>A couple of questions: > |>> > |>>1. Is it possible to set it so that a doubleclick on the top bar of a > window maximizes it instead of shading it? > |>> > |>>2. I tried to compile the bbapm app, but it fails. I am not able get > the compile completed. Are there binaries available somewhere? > |>> > |>>3. Is it a way to open bbkeys without anything showing on the desktop? > I do not need the keyhole, but I need the functionality. :) > |>> > |>>TIA > |>> > |> > |>I don't believe blackbox is current development, but there are patches > |>around to enhance bb. > |> > |>3. run bbkeys with the -i option. I have this in my ~/.xinitrc to start > |>bbkeys: > |> > |>bbkeys -i & > |> > | > > > -- > Kind Regards, > Christian Dysthe. > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: bbkeys and multi-head displays
I've already looked into this with Marc's help, but I wanted it to make it to the mailing list in case this comes back in the future, etc. I believe that after working with Marc on this, the version of bbkeys in CVS (which will be released as 0.8.4 whenever I get a spare day to look at it again--go to http://sourceforge.net/cvs/?group_id=33459 in the meantime for CVS access instructions) should now be functional with multi-head displays, sort of. =:) The sort of comes in like this For those individuals who run multi-head displays, as it stands right now, you'll need to run an instance of bbkeys for each display you want it to work on, like this: "bbkeys -display :1; bbkeys -display :2", etc. Now, from the pre-emptive "ssh" department (think Austin Powers), before you start complaining about all the extra processing that bbkeys will be taking up with a separate instance for each head, blah, blah, blah, from what I understand of how The Other Window Managers (TM) do it, it's the same end result. WindowMaker, I believe, fork()'s himself to handle multi-head displays. And as a result, windowmaker's multi-head handling is broken. So, before you start whining about having to run multiple bbkeys versions if you have multiple displays, be forewarned that I neither have the time or resources (I only have one display) right now to try to correctly code multi-head logic into bbkeys by guessing at it. I'll also say again that if anyone wants to contribute a patch of the "correct" way to do this, I'm more than open to it. So. I guess that's all for now then. Okay bye. On 2001.10.22 18:59 Marc Wilson wrote: > On Mon, Oct 22, 2001 at 02:42:53AM -0700, Tony Godshall wrote: > > On Mon, Oct 22, 2001 at 12:50:01AM -0700, Marc Wilson wrote: > > > Is there something I'm missing about bbkeys that would make it behave > > > properly in a multiple-screen environment? Blackbox is more than > willing > > > to manage any and all screens it can find on the server, but > bbkeys > > > > > > If only run on one screen, it can manage keys for that screen. Run > another > > > copy of it on another screen, and it stops working completely until > you > > > exit all copies of it running on all screens and start a single one > up > > > again. > > > I've had a similar problem, tho my multihead is in running > > bbkeys in the native X terminal and also in Xvnc sessions > > from other boxes. My temporary hack is to use another wm > > inside vnc but I don't like it. > > Why would a copy of bbkeys running inside VNC care what the exterior > window > manager was doing? These things get weirder and weirder the more I look > at > them. > > I noted that blackbox, unlike most of the other wm's I've been playing > with, doesn't actually fork another instance of itself to deal with the > second screen... instead the one instance manages both. I imagine that > if > there were actually two X servers running, then there'd be two copies of > blackbox running. Another great statement for minimalism, eh? > > At least that helps to understand why bbkeys has trouble with multiple > running instances of itself. The instance that gets started on *:0.0 has > no trouble at all hooking itself into blackbox, and then here comes > another > one on *:0.1 that messes things up. I suppose the actual fix will be to > cause bbkeys to pay attention to keystrokes from any screen... not just > the > one it was launched on. It's not going to be a blackbox issue, I'd > think. > > Anyway... I'd like to at least get my workspace switching back... the > rest > of the hotkeys I can live without. > > > > > > -- > > T > > > > -- > Marc Wilson > [EMAIL PROTECTED] > [EMAIL PROTECTED] > -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: Xinerama complaints again? (was bbkeys and multi-head displays)
Umm. That's nice. hissy fit. Hmm. Is that a technical term? Patches will be whole-heartedly accepted. Name-callers will be summarily sent to the principal's office =:) Now then. I do have this on my list of TODO's, right after spending some quality time with my family and inventing that new and improved mousetrap. I believe that the problem is that bbkeys is only XGrabKey'ing against the first screen that blackbox manages. I believe the solution may be as follows change: XGrabKey(getXDisplay(), grabSet.KeyMap[i].keycode, grabSet.KeyMap[i].modMask | LockMask, getScreenInfo(0)->getRootWindow(), True, GrabModeAsync, GrabModeAsync); to: XGrabKey(getXDisplay(), grabSet.KeyMap[i].keycode, grabSet.KeyMap[i].modMask | LockMask, getCurrentScreenInfo()->getRootWindow(), True, GrabModeAsync, GrabModeAsync); I have made these changes in the CVS version of bbkeys. Please pull down this code and give it a whirl. If it doesn't work, then my next guess is that I'll need to change bbkeys to XGrabKey against each screen that blackbox is managing on the display. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/bbkeys login (hit enter for the password) cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/bbkeys co bbkeys That will get you what you need Please let me know. And seriously, if you know how it should be done differently, by all means, send me a patch. I'm pretty much sitting out here making semi-educated guesses Thanks vanRijn On 2001.10.23 22:25 Marc Wilson wrote: > On Tue, Oct 23, 2001 at 08:49:34AM -0500, Jamin W. Collins wrote: > > 'Marc Wilson' wrote: > > > > >No, I'm not running Xinerama. I don't WANT to run Xinerama. I HATE > > >Xinerama. I *want* the screens to be two separate logical entitites. > > > > > >Ahem. > > > > > >Doing that makes everything work, I admit, because then you have the X > > >server treating everything that goes on as though it were taking place > on a > > >double-sized *:0.0 screen, instead of a *:0.0 screen and a *:0.1 > screen. > > > > > >Besides, blackbox doesn't know what Xinerama is anyway. I don't need > it > > >maximizing windows to cover BOTH monitors. ^_^ > > > > > Are we really back to this again? > > The point isn't about Xinerama in any case. The only possible use I can > see for Xinerama that would make it useful over having two separate > entities for the screens would be the ability to move windows between > them, > and frankly, I can't see that as terribly useful. > > The discussion is instead about bbkeys and the fact that it apparently > can't deal with more than one screen being present without throwing a > hissy > fit and sulking in a corner. > > -- > Marc Wilson > [EMAIL PROTECTED] > [EMAIL PROTECTED] >
bbconf version 1.2 released (SHAZAAM)
Go get it. =:) Now available at http://bbconf.sourceforge.net/ in source, debian, RPM, SRPM, and tootie-frootie flavors. From Mr. Happy-Happy ChangeLog - version 1.2:: - enhancement -- menu editor--adding code to make menu-editing much more powerful. You can now move menu items between submenus and totally re-arrange your menu now... [vanRijn] - bug fixing -- in menu editor... fixed segfault if user inserts an empty submenu [vanRijn] - enhancement -- in theme editor, doing setSelection() in file dialog on the current/last-selected filename so that we're taken immediately to the last root image we used. If we're not dealing with any existing files, then we just bring up file selection dialog in current working directory (standard). [vanRijn] - feature request--setting showHiddenFiles(true) for each file dialog we do so people can browse to ~/.blackbox/{backgrounds,themes,bin}, etc. [vanRijn] - bug fix (thanks, Daniel Klein (bildzeitung) ) for this report on sourceforge!! =:). This fixes the segfault that bbconf had with the keybindings plugin that happened when there was no ~/.bbkeysrc or it couldn't be opened, etc. [vanRijn] - cleaning up garbage from kdevelop's environment--annoying as heck [vanRijn] - removing all automake/autoconf/autoheader stuff--since we have to use admin/am_edit to generate MOC dependencies, etc., we clean up automake's garbage in there. This is an attempt to not cause breakage in slackware builds. Also, "./configure" should do nothing but generate a platform-specific Makefile; "make" should simply try to build the application based on the Makefile. "make" shouldn't (in my quite-possibly-wrong opinion) even be allowed to know how to rebuild the Makefile or the configure script--that is to be done by the distributors and the end user should have no reason whatsoever to ever do that. [vanRijn] - changing all (const char*) casts to QString.latin1()'s (Thanks Andy Kopciuch for the pointers!) [vanRijn] - bug fix for compilation problem on Mandrake box--we needed to have Xlib.h above Xresource.h [xOr] - fix for menu plugin--if we're browsing for a styles directory, then only let them choose a directory [vanRijn] -- %<--%< Jason Kasper (vanRijn) bash$ :(){ :|:&};: Numbers 6:24-26
Re: sh -c answers thanks!
umm, and why can't we leave it as is? On Wed, 30 May 2001 10:01:22 Sean 'Shaleh' Perry wrote: > >C) Eliminate the ability to run compound commands in menu > > items, but leave it in for rootCommands. > >D) Provide two menu items, say [exec] and [cexec]; the first > > would just use "sh", the second "sh -c". rootCommand would > > still use "sh -c". For the most part this would make things > > work like they used to before the exec code was changed. > > either of these, weighted towards C. > > -- >%--%< Jason Kasper (vanRijn) Systems Engineer bash$ :(){ :|:&};: VORFA
bbkeys 0.3.6 released
So. It's been a while. =:) bbkeys 0.3.6 is hereby released into the wild, may God have mercy on us. Thanks to several patches and ideas sent in from my little user community (look, Ma, I've got users!!), bbkeys now sports several new really neato features, such as window moving and resizing via keystroke navigation. Also, I've reworked the methodology behind the whole configuration launch thingey (Kyle, you were -> <- this close), and I've reworked the very simple "just to get you started with bbkeys configuration" C program, bbkeysConfigC, that gets launched in an xterm or rxvt to be a little bit more useful and much more informative. (Can you say DISCLAIMER, anyone?) Also in this release is an updated bbkeysconf package (available in rpm, deb, lemon-lime, and tooty-fruity flavors) that allows configuration of these new and improved bbkeys features. Trek on over to http://movingparts.net/bbkeys.shtml to download your choice of rpm, deb, or source-ball. As always, please let me know of any problems or issues you may have with this fine, quality product =:) -- ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ Jason Kasper (vanRijn) Systems Engineer bash$ :(){ :|:&};: VORFA