Re: SuSE bb
On Monday 21 January 2002 05:29, Gino Peregrini wrote:
I'd been using blackbox on Red Hat. I have changed to SuSE 7.3. I have bb
6.2 running well and have been over the menu.
I'm wondering how to set up bb to start with certain programs
running--bbpager and some dockapps, mostly. I know how to do that on Red
Hat 7.1 but haven't figured where to put a pointer to startbb.
I will appreciate any help.
I have been running SuSE for almost two weeks, initially I used KDE,
WindowMaker, and Gnome. KDE and WM are pretty neat, but their clutter makes
me appreciate blackbox all the more.
What I did on my SuSE 7.3 is this: In .xinitrc, there is a line saying # Add
your own lines here After that, insert the following lines:
#
# Add your own lines here...
#
if [ $WINDOWMANAGER == /usr/bin/X11/blackbox ]; then
source .blackbox/start
fi
(You might want to add a -f .blackbox/start just to be safe.) And put this in
.blackbox/start:
--- .blackbox/start ---
#!/bin/bash
function start {
delay=$2
if [ x_$delay == x_ ]; then
delay=2
fi
sleep $delay exec $1 /dev/null 21
}
# It's beginning to feel a lot like christmas
# start xsnow
# Start the BlackBox tools
start bbkeys -i -c /home/bo/.blackbox/bbkeysrc
start bbpager
start bbmail -w -c /home/bo/.blackbox/bbmailrc
# Set the background image
start xv -quit -root /home/bo/.blackbox/BlueStone.xpm
# Start the KDE aRts sound server
start artsd 3
--- *** ---
You can then change the startup applications yourself. The start function
takes two arguments, the commandline and an optional number of seconds before
it's run.
The idea is that all applications are put to sleep and start up a couple of
seconds later. This gives the blackbox windowmanager time enough to run.
By doing it this way, you can choose your window manager from KDM, and only
if you choose blackbox will the start file be run. MMJ, maybe it was an idea
to add something like this to SuSEs .xinitrc, to do this trick?
Feel free to use this in any way you want.
Bo.
BTW, the reason that I don't give bbpager any options is that it has a bug
that prevents it from loading an alternative file.
--
Bo Thorsen | Praestevejen 4
Free software developer| 5290 Marslev
SuSE Labs | Denmark
get workspace name
Hi, i wonder if it is possible to get the name of the current workspace. What i wont to do is: - press Alt-(1-9) to switch to a workspace - press F5 to open a new aterm this already works fine. Now i think there should be a little shell-script to get an environment variable ($WORKSPACE) and do a ssh to a workspace- relatet server. Puh - surely verry bad english. Sorry. But i think i made clear what i mean? :) thanks sascha
Re: get workspace name
On 21-Jan-2002 Sascha Huedepohl wrote: Hi, i wonder if it is possible to get the name of the current workspace. What i wont to do is: - press Alt-(1-9) to switch to a workspace - press F5 to open a new aterm this already works fine. Now i think there should be a little shell-script to get an environment variable ($WORKSPACE) and do a ssh to a workspace- relatet server. Puh - surely verry bad english. Sorry. But i think i made clear what i mean? :) once we support the NET WM spec you can write a little program which asks blackbox what is the number of the workspace currently, then ask it for the name of that workspace. You could then pass it to other scripts easily. http://www.freedesktop.org/standards/wm-spec/x104.html
Comments desired regarding possible upcoming changes
As we move forward in the code reorganization, I would like to remove some of the precompiler cruft. Which brings me to the following questions: a) are there any OS/2 people out there using blackbox. I would like to remove the OS/2 cruft if possible. 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? c) all of the above d) none of the above e) xOr's mom
Re: Comments desired regarding possible upcoming changes
On Mon, 21 Jan 2002 02:09:28 -0800 (PST) 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. No, thanks. 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? OK for me. I'd rather do without the toolbar, afaic.. I run bbkeys iconified (imho it needs no visible interface) I think so too! Marco
Re: Comments desired regarding possible upcoming changes
On Mon, 21 Jan 2002 02:09:28 -0800 (PST) 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 tried it. And from what I heard, I never want to. Happy with Linux. 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? I *always* use the slit, with GKrellM, bbpager, licq, etc. I also have bbkeys in there, because I have sometimes cycled through windows and suddenly had a little icon on my desktop which takes up an alt+tab position. Also, it helps me to see that it's vanished at times. Not often, but easier to check if it's in the slit. Now to have a way to turn off the toolbar. That would be nice. Just having it hidden can still cause small annoyances. I don't mind either of these still compiled in and active, but it would make sense that they can be turned off at run time. RPM's tend to have *everything* compiled in. I look forward to many years of Blackbox. Speedy -- Of all the things you can accomplish by screwing up your face and swearing into a darkened room, sleep is not one of them.
Re: get workspace name
In message: Re: get workspace name ([EMAIL PROTECTED]) on 21/01/2002 (Mon 01:05) Sean 'Shaleh' Perry wrote: once we support the NET WM spec you can write a little program which asks blackbox what is the number of the workspace currently, then ask it for the name of that workspace. You could then pass it to other scripts easily. Speaking of the NET WM spec . . . is anyone actively working on it now? I took it upon myself to try writing the icon-box application I mentioned a little while back and it seems that some critical atoms aren't being set right now. Before I start monkeying around in the bb code, is anyone else working on that? -Joe. -- Joe MacDonald :wq
Re: Comments desired regarding possible upcoming changes
On Mon, Jan 21, 2002 at 02:09:28AM -0800, Sean 'Shaleh' Perry wrote: As we move forward in the code reorganization, I would like to remove some of the precompiler cruft. Which brings me to the following questions: a) are there any OS/2 people out there using blackbox. I would like to remove the OS/2 cruft if possible. My OS/2 days are a fading memory. You can remove everything. 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? I compile with the slit. But except for 'bbkeys' I do not use it. I do not like icons of any kind on the 'screen', only a narrow, minimal toolbar. The only reason I use it with bbkeys is to have an easy way to put bbkeys in the top right corner (and 'autohide' it). I have no real use for the slit. What has always surprised me with blackbox is that the 'toolbar' has no functionality to speak of: you can switch workspaces, see the time and see which window has the focus. If you do have a toolbar why not a toolbar with some extra functionality: - the possibility to have things like the bbkeys keyhole icon ON the toolbar. - a built in battery load icon on the toolbar for laptop users. - the functionality on the toolbar supplied by the blackbox-taskbar-patch. (which is of course broken for blackbox-0.62). These additions (if possible without adding too much complexity), would enable people like me to make an aesthetically pleasing spartan desktop' without any ugly icons floating around. I would like to take this opportunity to thank Sean and the others for the nicely working 0.62. Alexander
Toolbar vs slit, was: Comments desired....
Hello,
Isn't what you say below an assertion that
1) You want the toolbar to do what the slit does, because
2) There is no need for *both* toolbar *and* slit in BB,
meaning that for the end user they functionally overlap, and all it's
really needed is*ONE* only way to puth a small, cpu light, unobtrusive
dashboard with aall the tools {time, link speed, cpu usage, new mail,
all the bbthings...} inside it?
Because that's *exactly* what I've been thinking for some time.
Marco
I compile with the slit. But except for 'bbkeys' I do not use it. I do
not like icons of any kind on the 'screen', only a narrow, minimal toolbar. The only
reason I use it with bbkeys is to have an easy way to
put bbkeys
in the top right corner (and 'autohide' it).
I have no real use for the slit.
What has always surprised me with blackbox is that the 'toolbar' has
no functionality to speak of: you can switch workspaces, see the time
and see which window has the focus.
If you do have a toolbar why not a toolbar with some extra functionality:
- the possibility to have things like the bbkeys keyhole icon ON the toolbar.
- a built in battery load icon on the toolbar for laptop users.
- the functionality on the toolbar supplied by the blackbox-taskbar-patch.
(which is of course broken for blackbox-0.62).
Re: Comments desired regarding possible upcoming changes
Sean 'Shaleh' Perry wrote: 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? I find the slit extremely useful in conjunction with KDE- and WindowMaker-apps. Dan Williams' dockslit-patch (allows the use of KDE-utilities like knotes, kppp,... in the slit) works with bb 0.62.0. I would even consider making this patch a compile-time option instead of the slit itself. markus -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Comments desired regarding possible upcoming changes
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. 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. 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. In short: my vote is to keep both slit and toolbar as compile-time options. After all, BB *is* trying to be (watch out, used-up standard-argument) minimalist. -Jan [1] Yes, thre's a patch for that - I might try it some day. -- finger [EMAIL PROTECTED]
Re: Toolbar vs slit, was: Comments desired....
On Mon, Jan 21, 2002 at 02:59:34PM +0100, Marco wrote:
Isn't what you say below an assertion that
1) You want the toolbar to do what the slit does, because
2) There is no need for *both* toolbar *and* slit in BB,
meaning that for the end user they functionally overlap, and all it's
really needed is*ONE* only way to puth a small, cpu light, unobtrusive
dashboard with aall the tools {time, link speed, cpu usage, new mail,
all the bbthings...} inside it?
Because that's *exactly* what I've been thinking for some time.
No. That is going to far.
I suspect most users of blackbox have a use for the slit.
I am only saying that I could do without it. But it doesn't hinder me.
(And if you do use it autohide is a nice feature).
But I am saying that I would like some extra functionality in the toolbar.
Alexander
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: Comments desired regarding possible upcoming changes
Jason 'vanRijn' Kasper [EMAIL PROTECTED] wrote: 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 D'uh! The reason I forgot about this is that I used to have licq in the slit, which then makes bbmail (being a lot smaller in size than the licq-dockapp-thiny) look ugly in the slit. But just those in the slit gets me what I want (except for strftime, but that should be easy enough to include). Thanks. -Jan -- finger [EMAIL PROTECTED]
Re: Comments desired regarding possible upcoming changes
What has always surprised me with blackbox is that the 'toolbar' has no functionality to speak of: you can switch workspaces, see the time and see which window has the focus. The toolbar is one of the things that makes blackbox unique. I like the very minimal and resource friendly clock, sometimes the 'what window has focus' is actually useful. If you do have a toolbar why not a toolbar with some extra functionality: - the possibility to have things like the bbkeys keyhole icon ON the toolbar. - a built in battery load icon on the toolbar for laptop users. - the functionality on the toolbar supplied by the blackbox-taskbar-patch. (which is of course broken for blackbox-0.62). I am not found of the icon on toolbar idea. It turns the toolbar into more of a panel and well, there are already plenty of those. As for the battery load idea, I like it and have considered it know and then before I became the blackbox hacker.
Re: Comments desired regarding possible upcoming changes
On 21-Jan-2002 Markus Ottenbacher wrote: Sean 'Shaleh' Perry wrote: 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? I find the slit extremely useful in conjunction with KDE- and WindowMaker-apps. Dan Williams' dockslit-patch (allows the use of KDE-utilities like knotes, kppp,... in the slit) works with bb 0.62.0. I would even consider making this patch a compile-time option instead of the slit itself. could you add a feature request on sf.net with a URL to this patch?
Re: Some minor font problems
On 21-Jan-2002 Wilbert Berendsen wrote: Hi, I use blackbox with the nl_NL@euro encoding (which has default charset iso-8859-15), and I have some font problems with the current bb releases (including 0.62). Many styles display a fixed font instead of lucidasans-10. Some display the font in an ugly way (small and almost illegible). When I replace the 'lucidasans-10' in the style files with '-bh-lucida-medium-r-normal-*-*-100-*-*-p-*-iso8859-*' everything is OK. yep. The fonts in question fail to tell XmbFontSet what encoding they use so the font code refuses to load it. This is the same thing causing people to have issues with the artwiz fonts. Last night I was able to irc with Brad and we worked out a test for whether multibyte support is actually needed by the locale. I have this coded up and in 0.62.1. I am sitting on it for a little while waiting for any bugs to come in.
Re: Comments desired regarding possible upcoming changes
On Mon, Jan21,02 09:15, Sean 'Shaleh' Perry wrote: I am not found of the icon on toolbar idea. It turns the toolbar into more of a panel and well, there are already plenty of those. As for the battery load idea, I like it and have considered it know and then before I became the blackbox hacker. OK. I can see one problem with this: where does it stop? _You_ like the battery load idea... what about the bbcpu app? the bbmem app? what about insert a whole host of other possible apps here? Sure, you're the main developer now, so you can kind of choose what goes, and what doesn't... but the inclusion of just one of the apps necessitates the ability to choose which app it is, and therefore moves you to developing a panel. Sure, it'd be one kickass panel because it's a bb panel, but why doesn't someone just develop a sparate bbpanel that plays nicely with bb? Then you could also have the option (run time!) to disable the toolbar. THAT makes alot more sense to me. DC -- Derek Cunningham [EMAIL PROTECTED] All men by nature desire to know. -- Aristotle. Registered Linux User Number 195825
Re: Comments desired regarding possible upcoming changes
On 21-Jan-2002 Derek Cunningham wrote: On Mon, Jan21,02 09:15, Sean 'Shaleh' Perry wrote: I am not found of the icon on toolbar idea. It turns the toolbar into more of a panel and well, there are already plenty of those. As for the battery load idea, I like it and have considered it know and then before I became the blackbox hacker. OK. I can see one problem with this: where does it stop? which is why the code is not there. The only sensible way to do this would be a plugin system. I have no plans to abuse blackbox in that way. No, I think I will hack a apm meter up and make it an unofficial patch like so many other feature additions in blackbox history. If I still used my laptop every day like I did a year or two ago I would have done this already. But lately I have spent all of my time with my 21 monitor and PII 450 system.
Re: Comments desired regarding possible upcoming changes
Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: The reason I want to remove the compile time option is because working around all of the #ifdef SLIT or BLAH in the code is just annoying. True. I actually do believe that the best way would be to remove those and instead offer the appropriate patches. Should make everybody happy (I know I am :). -Jan -- finger [EMAIL PROTECTED]
Re: Comments desired regarding possible upcoming changes
Jan Schaumann [EMAIL PROTECTED] wrote:
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
D'uh! The reason I forgot about this is that I used to have licq in the
slit, which then makes bbmail (being a lot smaller in size than the
licq-dockapp-thiny) look ugly in the slit. But just those in the slit
gets me what I want (except for strftime, but that should be easy enough
to include). Thanks.
Just for completeness' sake, attached are two patches:
one to remove the toolbar alltogether from BB, and one to allow bbdate
to use strftime-format (so that it accepts bbdate.strftimeFormat: %k:%M
%Y-%m-%d %a, for example, in its config-file).
I think I really dig this :) With my three bbapps snug in the slit, I
can place them around the screen as I like.
See http://www.netmeister.org/screenshots/bb_no_toolbar.png
-Jan
--
finger [EMAIL PROTECTED]
diff -burN bbdate-0.2.1-orig/LinkedList.hh bbdate-0.2.1/LinkedList.hh
--- bbdate-0.2.1-orig/LinkedList.hh Mon May 3 16:24:53 1999
+++ bbdate-0.2.1/LinkedList.hh Mon Jan 21 13:13:18 2002
@@ -63,7 +63,7 @@
int elements;
__llist_node *_first, *_last;
- friend __llist_iterator;
+ friend class __llist_iterator;
protected:
diff -burN bbdate-0.2.1-orig/bbdate.cc bbdate-0.2.1/bbdate.cc
--- bbdate-0.2.1-orig/bbdate.cc Mon May 3 16:24:53 1999
+++ bbdate-0.2.1/bbdate.cc Mon Jan 21 13:15:38 2002
@@ -70,9 +70,15 @@
unsigned long create_mask = CWBackPixmap|
CWOverrideRedirect |CWCursor|CWEventMask;
- frame.width=XTextWidth(resource-label.font, mm/dd/yy ,
+ if (resource-report.strftimeFormat)
+ frame.width=XTextWidth(resource-label.font,
+resource-report.strftimeFormat,
+
+strlen(resource-report.strftimeFormat)) +
+resource-frame.bevelWidth*4;
+ else
+ frame.width=XTextWidth(resource-label.font, mm/dd/yy ,
strlen( mm/dd/yy )) +
resource-frame.bevelWidth*4;
+
label.width=frame.width-2*resource-frame.bevelWidth;
frame.height=resource-label.font-ascent+
resource-label.font-descent+4*resource-frame.bevelWidth;
@@ -200,12 +206,23 @@
void ToolWindow::Redraw()
{
-char date[12];
+time_t tmp;
+struct tm *tt;
+
+char date[1024];
+if ((tmp = time(NULL)) != -1)
+ {
+ tt = localtime(tmp);
+ if (! ((resource-report.strftimeFormat)
+ (strftime(date, 1024, resource-report.strftimeFormat, tt
+ {
if (resource-report.euStyle)
sprintf(date, %02d/%02d/%02d , day, month, year);
else
sprintf(date, %02d/%02d/%02d , month, day, year);
+ }
+ }
XClearWindow(dpy, labelwin);
XDrawString(dpy, labelwin, frameGC, resource-frame.bevelWidth,
diff -burN bbdate-0.2.1-orig/resource.cc bbdate-0.2.1/resource.cc
--- bbdate-0.2.1-orig/resource.cc Sat May 8 06:55:26 1999
+++ bbdate-0.2.1/resource.ccMon Jan 21 13:13:18 2002
@@ -22,6 +22,7 @@
#include resource.hh
#include blackboxstyle.hh
+
Resource::Resource(ToolWindow *toolwindow):
BaseResource(toolwindow)
{
@@ -307,5 +308,16 @@
else
report.euStyle = False;
+ if (XrmGetResource(resource_db, bbdate.strftimeFormat,
+Bbdate.strftimeFormat, value_type, value))
+ {
+ report.euStyle = False;
+ report.strftimeFormat = (char *) malloc((value.size + 1) *
+sizeof(char));
+ memset(report.strftimeFormat, '\0', value.size + 1);
+ strncpy(report.strftimeFormat, value.addr, value.size);
+ }
+ else
+ report.strftimeFormat = NULL;
+
/* what to show.resources */
}
diff -burN bbdate-0.2.1-orig/resource.hh bbdate-0.2.1/resource.hh
--- bbdate-0.2.1-orig/resource.hh Mon May 3 16:24:53 1999
+++ bbdate-0.2.1/resource.hhMon Jan 21 13:13:18 2002
@@ -69,6 +69,7 @@
bool auto_raise;
unsigned int check_delay;
bool euStyle;
+ char *strftimeFormat;
};
diff -burN blackbox-0.62.0-orig/Makefile.in blackbox-0.62.0/Makefile.in
--- blackbox-0.62.0-orig/Makefile.inSat Jan 19 14:10:47 2002
+++ blackbox-0.62.0/Makefile.in Mon Jan 21 12:09:15 2002
@@ -71,6 +71,7 @@
PACKAGE = @PACKAGE@
SHAPE = @SHAPE@
SLIT = @SLIT@
+TOOLBAR =
Again on toolbar/slit redundancy
On Mon, Jan 21, 2002 12:24:09 at 12:24:09PM -0500, Derek Cunningham wrote: [snip] a panel. Sure, it'd be one kickass panel because it's a bb panel, but why doesn't someone just develop a sparate bbpanel that plays nicely with bb? Then you could also have the option (run time!) to disable the toolbar. THAT makes alot more sense to me. Whatever. As already noted, it seems to me that we come back time and again to realize (even when we don't want to say it openly...) that toolbar *and* slit don't make that much sense in a minimalistic environment, just make configuration uselessly difficult, because: they functionally overlap as far as the end user is concerned who is using any combination of them does want a ligthweight (visually tiny, minimal RAM/CPU usage) panel for monitoring purpose (time, mail, ppp speed...) and very little else (workspace and window lists) that panel should be fully configurable w.r.t to which bbthings it hosts, at the rc file level, **not** compiling Is it really a shame to admit this? The toolbar has always been in BB and gives it the look we love argument seems honestly silly to me. As long as you have that screen rectangle showing up, just a bit more extensible, does it really matter which code (slit/toolbar/The Next Thing) is drawing it, or how you call it for that matter? All this apart from how one reaches the other (essential) goal of not using the mouse, of course. Marco -- There can be no daily democracy without daily citizenship. Ralph Nader
Re: Comments desired regarding possible upcoming changes
On Mon, Jan 21, 2002 13:33:26 at 01:33:26PM -0500, Jan Schaumann wrote: Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: The reason I want to remove the compile time option is because working around all of the #ifdef SLIT or BLAH in the code is just annoying. True. I actually do believe that the best way would be to remove those and instead offer the appropriate patches. Should make everybody happy (I know I am :). Not really. Why should one be forced to get patches and recompile to get this? Marco -- We shall serve God, family and country, in that order, because without the one before it, each would perish.
Re: Toolbar vs slit, was: Comments desired....
On Mon, Jan 21, 2002 10:59:11 at 10:59:11AM -0500, Imad wrote: keyboard again). With the power of bbkeys, I -- and others -- need neither the toolbar *nor* the slit. It depends from what ones want. Icons on root window or panel are a poor substitute for keyboard shortcuts: they don't really add functionality, just help memory (or so people think.) and are easier to see. In this sense, hotkeys via bbkeys or whatever do really make toolbar/slit/panel/call it as you want/ useless. It is completely different when you want to monitor continuously some some function/performance in your machine (time, new mail, connection speed, cpu usage..) This is a totally different functionality, one that can only happen (if you need it of course) with some rectangle in the screen looking like some space ship control deck. If you need a control deck, one is enough, and this has nothing whatsoever to do with hotkeys. Changing workspaces/windows is the hotkey category of things. It really doesn't need the slit/toolbar unless you like it. bbtools belong to the control deck/car dashboard functionality: monitoring, altogether different from hotkeys. That requires a rectangle always on screen, regardless of its name. See also my message titled again on toolbar/slit redundancy. Thank you for your time, Marco -- Never let your sense of morals prevent you from doing what is right Salvor Hardin , Foundation
Re: Comments desired regarding possible upcoming changes
* Robin Jury ([EMAIL PROTECTED]) wrote: For my vote, a) clean the code. Of the three people in the world still using OS/2, I doubt any are using blackbox. Your ignorance is brilliant. I am certain that you probably are an indirect user of OS/2 without even realising it. -- Copyleft (c) 2001, Scott Moynes msg05051/pgp0.pgp Description: PGP signature
Re: Comments desired regarding possible upcoming changes
On Tue, Jan 22, 2002 09:19:07 at 09:19:07AM +1300, Robin Jury wrote: b) I always use the slit. The toolbar however, I ignore. How about any functionality that people want from the toolbar be put in the slit, and that can be placed wherever? Does anybody feel any strong need to have both at the same time? No, because they mostly do the same thing (see message again on blackbox/slit redundancy) Marco -- Reality is an illusion - perception is what counts.
toolbar
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]
RE: Comments desired regarding possible upcoming changes
No ignorance, I'm well aware of the uses of OS/2. However as a desktop environment for users who have a choice on the matter (let alone loading blackbox)it is not popular. Don't take it so seriously, we are only talking about computers, not something important. cheers Robin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Moynes Sent: Tuesday, 22 January 2002 9:28 a.m. To: [EMAIL PROTECTED] Subject: Re: Comments desired regarding possible upcoming changes * Robin Jury ([EMAIL PROTECTED]) wrote: For my vote, a) clean the code. Of the three people in the world still using OS/2, I doubt any are using blackbox. Your ignorance is brilliant. I am certain that you probably are an indirect user of OS/2 without even realising it. -- Copyleft (c) 2001, Scott Moynes
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: Toolbar vs slit, was: Comments desired....
On Mon, 2002-01-21 at 07:59, Marco wrote:
meaning that for the end user they functionally overlap, and all it's
really needed is*ONE* only way to puth a small, cpu light, unobtrusive
dashboard with aall the tools {time, link speed, cpu usage, new mail,
all the bbthings...} inside it?
Because that's *exactly* what I've been thinking for some time.
Does GKrellM not meet these requirements?
Jamin W. Collins
Re: Comments desired regarding possible upcoming changes
On Mon, 2002-01-21 at 16:36, Mads Martin Jørgensen wrote: In short, I'm for the removal of the Toolbar and functionality moved to the Slit. As long as one not would be stuck with anything unwanted in the slit. Certainly not. I didn't intend to imply that anyone would be forced, to have them in the slit, rather that they could have them in the slit. Perhaps as configuration options? Jamin W. Collins
Re: toolbar
On 21 Jan 2002, Jason 'vanRijn' Kasper wrote: 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. I also have to agree here. I use the toolbar to tell which workspace I happen to be in, which window that happen to be focused and what time it is. I also use to switch workspaces. I do, however, not use anything that requires the slit which is why I disable it at compile time. This is why I vote to keep the toolbar. The slit can be made a run-time option if it simplifies the code (not perhaps making it smaller, more in the sense of readability). -- John Eckerdal
Re: Comments desired regarding possible upcoming changes
On Mon, Jan 21, 2002 at 04:30:54PM -0600, Jamin W. Collins wrote: On Mon, 2002-01-21 at 14:19, Robin Jury wrote: b) I always use the slit. The toolbar however, I ignore. How about any functionality that people want from the toolbar be put in the slit, and that can be placed wherever? Does anybody feel any strong need to have both at the same time? I like this idea. It satisfies almost everyone involved. If all three options (Workspace Cycle, Active Window Cycle, and Date display) were slit options (I know they can be gathered with external applications, but is this minimal?) In short, I'm for the removal of the Toolbar and functionality moved to the Slit. There are at least 2 types of arguments for/against both toolbar/slit: 1) functional arguments: - it is probably possible to gather all the functionality of the toolbar in the slit - it is probably possible to gather all or allmost all the functionality of the slit in the toolbar. But neither of these extreme solutions gives the best functionality under all conditions and at all times. A number of reasons why the toolbar remains handy have already been given by others so I won't repeat them. Given that both the toolbar and the slit can be 'autohidden' I see no reason why either should be removed. Keep both in! 2) aesthetic arguments: Some of us really care about the appearance of the desktop. I personally like a very sparse desktop with absolutely no icons on it and just a small, narrow toolbar. The theme should be refined, with a good colour scheme (like a lot of the blackbox themes). The only pagers I find acceptable are the Enlightenment pagers (under certain nice themes). Something like GKrellM has the effect of putting a blaring jukebox with flashing lights in your room to play Gesualdo madrigals. WindowMaker is an excellent functional desktop but very crude and ugly under all themes I have seen (ugly big icons). Judging from the pictures on the blackbox sites I find the looks of the bbtools icons not to my taste. And they are probably quite big. (And that, big and a crude appearance, is certainly true for WindowMaker dockapps and KDE applets). The big advantage of using only a toolbaar from my point of view is that it is very 'refined' (under allmost all the excellent blackbox themes) and you only need text, colors and relief for the available functionality. (Even a battery monitor for laptop users on the toolbar would only need to use text). This makes it much easier to generate a tastefull personal desktop. There are bound to be almost as many arguments for or against keeping or removing the toolbar or slit as there are blackbox users. I would plead to keep both. With autohide functionality. Or, if possible, a choice at compilation time. Alexander
Re: Comments desired regarding possible upcoming changes
On Mon, Jan 21, 2002 at 04:30:54PM -0600, Jamin W. Collins wrote: On Mon, 2002-01-21 at 14:19, Robin Jury wrote: b) I always use the slit. The toolbar however, I ignore. How about any functionality that people want from the toolbar be put in the slit, and that can be placed wherever? Does anybody feel any strong need to have both at the same time? I like this idea. It satisfies almost everyone involved. If all three options (Workspace Cycle, Active Window Cycle, and Date display) were slit options (I know they can be gathered with external applications, but is this minimal?) In short, I'm for the removal of the Toolbar and functionality moved to the Slit. There are at least 2 types of arguments for/against both toolbar/slit: 1) functional arguments: - it is probably possible to gather all the functionality of the toolbar in the slit - it is probably possible to gather all or allmost all the functionality of the slit in the toolbar. But neither of these extreme solutions gives the best functionality under all conditions and at all times. A number of reasons why the toolbar remains handy have already been given by others so I won't repeat them. Given that both the toolbar and the slit can be 'autohidden' I see no reason why either should be removed. Keep both in! 2) aesthetic arguments: Some of us really care about the appearance of the desktop. I personally like a very sparse desktop with absolutely no icons on it and just a small, narrow toolbar. The theme should be refined, with a good colour scheme (like allmost all the blackbox themes). The only pagers I find acceptable are the Enlightenment pagers (under certain nice themes). Something like GKrellM has the effect of putting a blaring jukebox with flashing lights in your room to play Gesualdo's madrigals. WindowMaker is an excellent functional desktop but very crude and ugly under all themes I have seen (ugly big icons). Judging from the pictures on the blackbox sites I find the looks of the tools icons not to my taste. And they are probably quite big. (And that, big and a crude appearance, is certainly true for WindowMaker dockapps and KDE applets). The big advantage of using only a toolbaar from my point of view is that it is very 'refined' (under allmost all the excellent blackbox themes) and you only need text, colors and relief for the available functionality. (Even a battery monitor for laptop users on the toolbar would only need to use text). This makes it much easier to generate a tastefull personal desktop. There are bound to be almost as many arguments for or against keeping or removing the toolbar or slit as there are blackbox users. I would plead to keep both. With autohide functionality. This will certainly not make blackbox a plodding memory hogg with millions of lines of code. Alexander Jamin W. Collins
Re: Comments desired regarding possible upcoming changes
Let's put the toolbar in the slit and the slit in the toolbar, so we can be cool and have the first doubly-recursive FEATURE, as opposed to the lame, traditional acronyms. Yah? On Tue, Jan 22, 2002 at 12:53:47AM +0100, Alexander Volovics wrote: On Mon, Jan 21, 2002 at 04:30:54PM -0600, Jamin W. Collins wrote: On Mon, 2002-01-21 at 14:19, Robin Jury wrote: b) I always use the slit. The toolbar however, I ignore. How about any functionality that people want from the toolbar be put in the slit, and that can be placed wherever? Does anybody feel any strong need to have both at the same time? I like this idea. It satisfies almost everyone involved. If all three options (Workspace Cycle, Active Window Cycle, and Date display) were slit options (I know they can be gathered with external applications, but is this minimal?) In short, I'm for the removal of the Toolbar and functionality moved to the Slit.
Xinerama support
I can hear the masses screaming, *ra*, *rah* Anyway. I have some code to add Xinerama support to Blackbox... (still waiting for the cheering to die down). For those of you who don't know what Xinerama is it allows multiple monitors to be used as a single monitor. The problem is things like Blackbox placing windows across window borders and menus spanning windows and things like that. If anyone would like to test it I'm posting it on my webserver (please no trying to take it down, that would make me very unhappy) at http://xentac.net/~jchu/black. I basically modified the 0.62.0 Debian package. You have the choice of taking the source or an easily digestible Debian package. Be careful though guys, the Debian package will be overwritten on the next update (I suggest you use your favorite package manager and set blackbox on hold at the moment). Mostly just stress testing now. I haven't yet tried running it without Xinerama turned on. If it broke anything there it'd be a very quick fix. I've also only tested it on the screen 0 is left of screen 1 scenario (mine). I'd like to hear results of other Xinerama setups. I babble too much. Go forth and test. Jason (Xentac) Chu
Re: toolbar
Me too! I say keep the toolbar. I haven't been using bb very long, but I find that it helps me keep track of what's going on in all my workspaces. I enjoy being able to effortlessly and quickly flip between 10 different workspaces with apps open and ready to go. I leave it always on top across the top center of my desktop. I find the toolbar helps newcomers work quickly and efficiently. Just my 2 cents. Mike 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]
Re: Xinerama support
On Mon, 2002-01-21 at 21:13, Jason Chu wrote: I have some code to add Xinerama support to Blackbox... (still waiting for the cheering to die down). For those of you who don't know what Xinerama is it allows multiple monitors to be used as a single monitor. The problem is things like Blackbox placing windows across window borders and menus spanning windows and things like that. I too use Xinerama in Blackbox, and have some difficulty understanding the frequently voiced viewpoint that Blackbox's Xinerama support is broken in some way. There is nothing broken concerning Blackbox's current Xinerama support. The idea behind Xinerama is simple, to make multiple physical screens function as one logical screen. Thus, it should be possible (and is under Blackbox currently) for items, that would normally appear anywhere on a single physical screen, to open anywhere on the one (Xinerama provided) logical screen. Even if this means that it opens partially on two different physical screens. What is currently being proposed, is a patch to create artificial boundaries (that in this case happen to coincide with the physical monitor sizes) that items should not cross. While this may sound like a nice feature, that's all it is. It has nothing to do with Xinerama (if you don't believe me check with the developers, I have). So, please take it at what it is, a patch to add artificial no-cross boundary generation to Blackbox. I see no need for patches of this nature to be included in Blackbox. Jamin W. Collins
Re: Xinerama support
On Mon, Jan 21, 2002 at 10:15:27PM -0600, Jamin W. Collins wrote: I too use Xinerama in Blackbox, and have some difficulty understanding the frequently voiced viewpoint that Blackbox's Xinerama support is broken in some way. There is nothing broken concerning Blackbox's current Xinerama support. I haven't used bb with xinerama, but i believe that there are certain common-sense issues which bb does not address when used with xinerama. when you maximize a window currently in bb, i believe that the window spans both screens? (this is not correct behavior) also, i don't think that bb addresses the dead area issue, when xinerama is used with monitors of different resolution: if you have a monitor running at 1280x1024 and one that runs at 800x600, non-xinerama aware wm's see the screen as one big rectangle, ignoring the fact that part of it cannot be used. (since the second monitor is much smaller.) both of these issues are discussed in the xinerama howto at linuxdoc.org. my 01 The idea behind Xinerama is simple, to make multiple physical screens function as one logical screen. Thus, it should be possible (and is under Blackbox currently) for items, that would normally appear anywhere on a single physical screen, to open anywhere on the one (Xinerama provided) logical screen. Even if this means that it opens partially on two different physical screens. What is currently being proposed, is a patch to create artificial boundaries (that in this case happen to coincide with the physical monitor sizes) that items should not cross. While this may sound like a nice feature, that's all it is. It has nothing to do with Xinerama (if you don't believe me check with the developers, I have). So, please take it at what it is, a patch to add artificial no-cross boundary generation to Blackbox. I see no need for patches of this nature to be included in Blackbox. Jamin W. Collins
Re: Xinerama support
It's not Xinerama support per-se, it's more like Xinerama awareness. I can understand your concerns with adding artifical boundaries in Blackbox but there is a problem when Blackbox decides to pop up a window in a part of my screen that doesn't exist (it can do that if the situation is right: I have two screens with two different resolutions and on the screen with the smaller resolution I have a window that's bottom bar is at the border where the screen no longer exists. Suddenly I have a window that I can't see or get to, but Blackbox tells me it's there). At the same time it is very difficult to read menus across screens and windows shouldn't be popped up across displays either. Personally I believe a window manager should be smart enough to place windows properly, artifically calculated or not. On Mon, 2002-01-21 at 20:15, Jamin W. Collins wrote: On Mon, 2002-01-21 at 21:13, Jason Chu wrote: I have some code to add Xinerama support to Blackbox... (still waiting for the cheering to die down). For those of you who don't know what Xinerama is it allows multiple monitors to be used as a single monitor. The problem is things like Blackbox placing windows across window borders and menus spanning windows and things like that. I too use Xinerama in Blackbox, and have some difficulty understanding the frequently voiced viewpoint that Blackbox's Xinerama support is broken in some way. There is nothing broken concerning Blackbox's current Xinerama support. The idea behind Xinerama is simple, to make multiple physical screens function as one logical screen. Thus, it should be possible (and is under Blackbox currently) for items, that would normally appear anywhere on a single physical screen, to open anywhere on the one (Xinerama provided) logical screen. Even if this means that it opens partially on two different physical screens. What is currently being proposed, is a patch to create artificial boundaries (that in this case happen to coincide with the physical monitor sizes) that items should not cross. While this may sound like a nice feature, that's all it is. It has nothing to do with Xinerama (if you don't believe me check with the developers, I have). So, please take it at what it is, a patch to add artificial no-cross boundary generation to Blackbox. I see no need for patches of this nature to be included in Blackbox. Jamin W. Collins
Re: Xinerama support
On 21 Jan 2002 21:44:52 -0800 Jason Chu [EMAIL PROTECTED] wrote: It's not Xinerama support per-se, it's more like Xinerama awareness. I can understand your concerns with adding artifical boundaries in Blackbox but there is a problem when Blackbox decides to pop up a window in a part of my screen that doesn't exist (it can do that if the situation is right: I have two screens with two different resolutions and on the screen with the smaller resolution I have a window that's bottom bar is at the border where the screen no longer exists. Suddenly I have a window that I can't see or get to, but Blackbox tells me it's there). At the same time it is very difficult to read menus across screens and windows shouldn't be popped up across displays either. Personally I believe a window manager should be smart enough to place windows properly, artifically calculated or not. By the way, using my proposed SmartPlacement algorithm, it is possible to add a bit of Xinerama awareness very easily. The algorithm starts out with one rectangle of the screen's size, but you could it very easily make start out with two (or more) rectangles of the both screen's sizes. Also the maximize code would have to be made Xinerama aware (optionally?). Personally I don't care much of the menu placement etc being made Xinerama aware. just my ¤ 0.02 :) PS My proposed smartplacement algorithm lives at http://www.xs4all.nl/~wbsoft/linux/projects/docs/SmartPlacement.tar.gz It's a lyx and PS file. Sorry for no HTML, but i have no tex-html converter installed right now. -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/)
Re: toolbar
On Monday 21 January 2002 15:44, it is widely held that Jason 'vanRijn' Kasper wrote: And, I use the toolbar often for workspace-navigation, etc. One thing that could be added to the toolbar would be that if you click on the Workspace name a list of all the Workspaces appears, so I don't have to cycle -- then again, that would be more logically added to the workspace menu... Douglas
Re: toolbar
On Mon, Jan 21, 2002 at 10:41:33PM -0500, Nexist Xenda'ths wrote: On Monday 21 January 2002 15:44, it is widely held that Jason 'vanRijn' Kasper wrote: And, I use the toolbar often for workspace-navigation, etc. One thing that could be added to the toolbar would be that if you click on the Workspace name a list of all the Workspaces appears, so I don't have to cycle -- then again, that would be more logically added to the workspace menu... left-click on one of the workspaces in the menu. :) xOr -- I am damn unsatisfied to be killed in this way. msg05073/pgp0.pgp Description: PGP signature
