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
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$ :(){ :|:};:
`--//
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
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$ :(){ :|:};:
`--//
bbconf 1.6 hereby released into the wild... whizzzzzz
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: 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: 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: 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: .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:
snippity
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: .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: 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: 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
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: 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
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: 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
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: 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: 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
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: 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 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
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: (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.
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: 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.
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: 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 filename 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 09:20, Derek Cunningham wrote:
snip
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.
more snipping
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
Re: bbappconf
On Wed, 2001-11-14 at 11:55, Derek Cunningham wrote:
snipping
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
[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 alt+M and then press control+Up 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 patch snipped for brevity
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: 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: 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: 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.
/vanRijn
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
deleted
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. wah!
--
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, soapbox./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./soapbox [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
