Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sat, Mar02,02 20: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 .. yes vote here. DC -- Derek Cunningham [EMAIL PROTECTED] "Human beings act intelligently only after they have exhausted the alternatives" -- Abba Eban Registered Linux User Number 195825
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On 03-Apr-2001 Creighton Samuels wrote: > I say ney, and on a related note where can I find the NETWM spec? I have > searched and failed. www.freestandards.org, follow the link to the desktop group.
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sun, 03 Mar 2002 02:19:37 -0800 (PST) "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > I like the idea of giving people the ability to move the buttons around. My > concern is that allowing them to also remove buttons could cost the user > some feedback. Allowing the user to remove buttons wouldn't cost them any feedback. If the user chooses to do so it could, but the option itself wouldn't. I'm not demanding this be added (it's simple enough to patch in), but I think we should assume the user knows what their doing and allow this convenience if they choose. :-) -- Joseph Applegate (SB-X) [EMAIL PROTECTED] UIN: 9788597
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sat, 2 Mar 2002 20:29:37 -0800 Marc Wilson <[EMAIL PROTECTED]> wrote: > It adds a resource to your .blackboxrc like so: > session.titlebarLayout: LIMC > Please note that I did *NOT* create the patch, nor am I claiming credit for > it. I merely want to use it. ^_^ Thank you very much! At least for bringing the patch to my attention. It is wonderful, because up to now I have been manually changing the decor layout with each new BB release. Now it is configurable. Absolutely wonderful. If we are collectively deciding on whetherto add it in or not, I vote yes. Make it an compile-time option if it bothers people/slows anything down. -- Joseph Applegate (SB-X) [EMAIL PROTECTED] UIN: 9788597
Re: blackbox-0.62.1-custom_titlebar-fab.patch
I say ney, and on a related note where can I find the NETWM spec? I have searched and
failed
On Sat, Mar 02, 2002 at 11:39:50PM -0500, Jason 'vanRijn' Kasper wrote:
> 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: blackbox-0.62.1-custom_titlebar-fab.patch
> > It adds a resource to your .blackboxrc like so: > > session.titlebarLayout: LIMC > > where: L == window label > I == iconify button > M == maximize button > C == close button > > If you don't have it already there, it defaults it to the standard blackbox > arrangement (that being 'ILMC') and adds it for you. If you want to leave > a button out, you can edit .blackboxrc yourself and do so. ^_^ > Here are my thoughts on this. The toolbar buttons serve not only as decor and function but also give clues to the window's type. A dialog box (transient window in X speak) does not get full window dressing. If the user asks for say, only the close button how do they get this information? (Yes, the label is mandatory). I like the idea of giving people the ability to move the buttons around. My concern is that allowing them to also remove buttons could cost the user some feedback. I need to read the patch again. Last time I looked it did very little sanity checking. That was my other concern.
Offtopic: C Coding Practice (was: Re: blackbox-0.62.1-custom_titlebar-fab.patch)
[Followups should probably go to either news:comp.lang.c or to me
personally.]
Circa 2002-Mar-02 23:35:26 -0800 dixit Marc Wilson:
: On Sun, Mar 03, 2002 at 01:58:56AM -0500, Jim Knoble wrote:
: > The indentation is misleading. If you *really* don't want to use
: > brackets around a single statement, i recommend this style:
:
: Well, yeah. But you shouldn't be using the brackets to cover up the poor
: coding practices (lousy indenting).
The use of brackets here:
if (blah) {
haha();
} else {
heehee();
}
doesn't "cover up" the indentation. Rather, the use of brackets makes
*explicit* what is otherwise *implicit*, i.e., which statements are
grouped with which clause of the compound 'if' statement. Putting a
single-statement if or if/else on a single line, like so:
if (blah) haha(); else heehee();
uses indentation to make *obvious* what is implicit, i.e. that each
clause contains only one statement. The braces tell the compiler (and,
incidentally, the reader) the programmer's intent, while the
single-line format tells only the reader the programmer's intent. In
most cases, it's better to use the braces than not to---it actually
*prevents* mistakes. In some cases, it's in fact necessary to use the
braces in order to avoid dangling else clauses, e.g.:
if (blah) if (haha) heehee(); else woohoo();
To whom does the else belong: the first if, or the second? One of
those dusty books on your shelf---you know, the one with the table of
operators and their precedence, and with the list of the "usual type
conversions"---tells you which one the compiler will pick, but how do
you remember that, especially when you have other languages to deal
with where the compiler or interpreter picks the other one? Better to
be explicit and tell the compiler (not to mention the reader) what you
really mean; either:
if (blah) {
if (haha) {
heehee();
} else {
woohoo();
}
}
or:
if (blah) {
if (haha) {
heehee();
}
} else {
woohoo();
}
For the same reason, using parentheses in an expression to order
operators and operands, even when operator precedence would pick the
"right" order, can be good practice (as long as it doesn't obsure the
expression). Again, it makes explicit (to both the compiler and the
reader) what the intent of the programmer is---thus helping to prevent
mistakes.
Of course, the programmer could simply make it obvious to the reader
what the precedence of the expression should be, by adding or removing
whitespace in strategic locations ... but that doesn't do anything to
prevent the *compiler* from misinterpreting the expression. See the
difference?
--
jim knoble | [EMAIL PROTECTED] | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
msg05690/pgp0.pgp
Description: PGP signature
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sun, Mar 03, 2002 at 01:58:56AM -0500, Jim Knoble wrote: > The indentation is misleading. If you *really* don't want to use > brackets around a single statement, i recommend this style: Well, yeah. But you shouldn't be using the brackets to cover up the poor coding practices (lousy indenting). -- Marc Wilson [EMAIL PROTECTED] http://members.cox.net/msw
Re: blackbox-0.62.1-custom_titlebar-fab.patch
Circa 2002-Mar-02 21:34:35 -0800 dixit Sean 'Shaleh' Perry:
: > You *are* bracket-happy though, you know. ^_^
:
: the else could safely lose the {}. However I find the else then
: gets lots easily. It is also my experience that every time i have a
: place where I can get away without braces I end up needing them
: later. Since I code in python a lot, I find that I forget to add
: them. So as compensation I just add them by default.
This is merely good coding practice. Even experienced C programmers
forget to add braces, especially in places such as:
if (blah)
haha();
else
heehee();
woohoo(); /* New statement, looks like it's part of 'else', */
/* but really it's not: it gets executed regardless */
/* of whether 'blah' is true or false. */
Or:
for (blah = 0; blah < haha; blah++)
something();
something_else(); /* <-- This looks like it's part of a for() */
/* loop, but it's not. It only gets done once, */
/* after the loop is finished. */
The indentation is misleading. If you *really* don't want to use
brackets around a single statement, i recommend this style:
if (blah) haha();
if (heehee) woohoo(); else wheee();
for (a; b; c) something();
so that it's fully clear there's exactly one statement there.
--
jim knoble | [EMAIL PROTECTED] | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
msg05686/pgp0.pgp
Description: PGP signature
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sat, 2 Mar 2002 20:29:37 -0800 Marc Wilson <[EMAIL PROTECTED]> wrote: > Ok, here's another one that shaleh says is never gonna make it into > blackbox... > Please note that I did *NOT* create the patch, nor am I claiming > credit for it. I merely want to use it. ^_^ > Marc Wilson Thankyou, Thankyou, Thankyou, Thankyou and Thankyou!!! This is the greatest patch that has ever been applied to blackbox. I know that you aren't taking credit for it, but you made it work for 0.62.1 & you posted it to the mailing list; therefore you are my #1 favorite human being for the next 24 hours!! -- Regards, John Kennison Student (Bachelor of Business Information Systems)
Re: blackbox-0.62.1-custom_titlebar-fab.patch
>
> You *are* bracket-happy though, you know. ^_^
>
oh?
You must be referring to this:
if (test) {
..
..
..
} else {
..
}
the else could safely lose the {}. However I find the else then gets lots
easily. It is also my experience that every time i have a place where I can
get away without braces I end up needing them later. Since I code in python a
lot, I find that I forget to add them. So as compensation I just add them by
default.
Re: blackbox-0.62.1-custom_titlebar-fab.patch
On Sat, Mar 02, 2002 at 08:37:06PM -0800, 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 .. Heh... maybe I shouldn't have wasted my time, then. I tried to follow your bracket style, but gave up for Window.cc, and patched a 0.61.1 and lifted the new code verbatim. Doing this is a way to tickle umpteen-year-old C skills in my head, but I wasn't THAT interested in making it look pretty. You *are* bracket-happy though, you know. ^_^ -- Marc Wilson [EMAIL PROTECTED] http://members.cox.net/msw
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: blackbox-0.62.1-custom_titlebar-fab.patch
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 ..
blackbox-0.62.1-custom_titlebar-fab.patch
Ok, here's another one that shaleh says is never gonna make it into
blackbox...
I like being able to rearrange the buttons, or for that matter, delete
them. So I re-did this one for 0.62.1. It's not pretty, it doesn't
particularly follow shaleh's idea of proper coding (he's bracket happy), it
just works.
It adds a resource to your .blackboxrc like so:
session.titlebarLayout: LIMC
where: L == window label
I == iconify button
M == maximize button
C == close button
If you don't have it already there, it defaults it to the standard blackbox
arrangement (that being 'ILMC') and adds it for you. If you want to leave
a button out, you can edit .blackboxrc yourself and do so. ^_^
Please note that I did *NOT* create the patch, nor am I claiming credit for
it. I merely want to use it. ^_^
(ok, now I get to work on taskbar_menu, which is the OTHER one I want to
use, and which makes mouse_wheel unnecessary...)
--
Marc Wilson
[EMAIL PROTECTED]
http://members.cox.net/msw
diff -urN blackbox-0.62.1.orig/configure blackbox-0.62.1/configure
--- blackbox-0.62.1.orig/configure Fri Jan 25 02:50:25 2002
+++ blackbox-0.62.1/configure Sat Mar 2 20:11:11 2002
@@ -714,7 +714,7 @@
PACKAGE=blackbox
-VERSION=0.62.1pre0
+VERSION=0.62.1
if test "`cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then
{ echo "configure: error: source directory already configured; run "make distclean"
there first" 1>&2; exit 1; }
diff -urN blackbox-0.62.1.orig/configure.in blackbox-0.62.1/configure.in
--- blackbox-0.62.1.orig/configure.in Fri Jan 25 02:50:18 2002
+++ blackbox-0.62.1/configure.inSat Mar 2 20:11:39 2002
@@ -1,7 +1,7 @@
dnl configure.in for Blackbox - an X11 Window manager
dnl Initialize autoconf and automake
AC_INIT(src/blackbox.cc)
-AM_INIT_AUTOMAKE(blackbox,0.62.1pre0,no-define)
+AM_INIT_AUTOMAKE(blackbox,0.62.1,no-define)
dnl Determine default prefix
test x$prefix = "xNONE" && prefix="$ac_default_prefix"
diff -urN blackbox-0.62.1.orig/src/Window.cc blackbox-0.62.1/src/Window.cc
--- blackbox-0.62.1.orig/src/Window.cc Sat Jan 19 08:06:30 2002
+++ blackbox-0.62.1/src/Window.cc Sat Mar 2 20:05:25 2002
@@ -741,50 +741,103 @@
void BlackboxWindow::positionButtons(Bool redecorate_label) {
- unsigned int bw = frame.button_w + frame.bevel_w + 1,
-by = frame.bevel_w + 1, lx = by, lw = frame.width - by;
+ char *format = (char *) blackbox->getTitleBarLayout();
- if (decorations.iconify && frame.iconify_button != None) {
-XMoveResizeWindow(display, frame.iconify_button, by, by,
- frame.button_w, frame.button_h);
-XMapWindow(display, frame.iconify_button);
-XClearWindow(display, frame.iconify_button);
-
-lx += bw;
-lw -= bw;
- } else if (frame.iconify_button) {
-XUnmapWindow(display, frame.iconify_button);
+ unsigned int x = 0;
+ unsigned int ty = frame.bevel_w + 1;
+ unsigned int tx = frame.bevel_w + 1;
+ unsigned int bw = frame.button_w + frame.bevel_w + 1;
+ unsigned int bc = strlen(format) - 1;
+
+ if (!decorations.close) bc -= 1;
+ if (!decorations.iconify) bc -= 1;
+ if (!decorations.maximize) bc -= 1;
+
+ frame.label_w = frame.width - (bc * bw) - (2 * frame.bevel_w) - 1;
+
+ while (&format[x] != "" && x <= 3) {
+switch(format[x++]){
+ case 'C':
+ {
+ tx += BlackboxWindow::positionCloseButton(tx,ty);
+ break;
+ }
+ case 'I':
+ {
+ tx += BlackboxWindow::positionIconifyButton(tx,ty);
+ break;
+ }
+ case 'M':
+ {
+ tx += BlackboxWindow::positionMaximizeButton(tx,ty);
+ break;
+ }
+ case 'L':
+ {
+ tx += BlackboxWindow::positionLabel(tx,ty);
+ break;
+ }
+}
}
- int bx = frame.width - bw;
+
+ if (redecorate_label) decorateLabel();
+ redrawLabel();
+ redrawAllButtons();
+
+
+}
+
+
+unsigned int BlackboxWindow::positionCloseButton(unsigned int tx, unsigned int ty) {
if (decorations.close && frame.close_button != None) {
-XMoveResizeWindow(display, frame.close_button, bx, by,
- frame.button_w, frame.button_h);
+XMoveResizeWindow(display, frame.close_button, tx, ty, frame.button_w,
+frame.button_h);
XMapWindow(display, frame.close_button);
XClearWindow(display, frame.close_button);
+return frame.button_w + frame.bevel_w + 1;
-bx -= bw;
-lw -= bw;
} else if (frame.close_button) {
XUnmapWindow(display, frame.close_button);
+return 0;
+ }
+
+}
+
+unsigned int BlackboxWindow::positionIconifyButton(unsigned int tx, unsigned int ty) {
+
+ if (decorations.iconify && frame.iconify_button != None) {
+XMoveResizeWindow(display, frame.iconify_button, tx, ty, frame.button_w,
+frame.button_h);
+XMapWindow(display, frame.iconify_button);
+XClearWindow(display, frame.iconify_button);
+return frame.button_w + frame.bevel_w + 1;
+
+ } else if (frame.iconif
