Is Blackbox still today a recommended or outdated WM ?

spartrekus · 2017-05-31 19:30:53

Hello,

The Blackbox WM is today still available on the repositories. Blackbox has always been a reliable WM. Since some years, there are less developments, and it may look a bit old, maybe

Small, stable, WM is no longer fashion, compared to modern, high features, heavy, comfortable, WMs and environment/desktop.

herewith the not so much maintained website:
http://blackboxwm.sourceforge.net/AboutBlackbox

Compiling didn't work much actually.

Image.cc: In member function 'void bt::Image::hgradient(const bt::Color&, const bt::Color&, bool)':
Image.cc:1350:42: error: 'memcpy' was not declared in this scope
       memcpy(p, data, width * sizeof(RGB));
                                          ^
Makefile:374: recipe for target 'Image.lo' failed
make[2]: *** [Image.lo] Error 1
make[2]: Leaving directory '/tmp/blackbox-0.70.1.orig/lib'
Makefile:285: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/blackbox-0.70.1.orig'
Makefile:212: recipe for target 'all' failed
make: *** [all] Error 2
linux@acer:/tmp/blackbox-0.70.1.orig$

Last edited by spartrekus (2017-05-31 19:35:19)

FOSSuser · 2017-06-01 09:06:53

If I remember, I switched to Fluxbox because it wasn't being maintained, but there are a lot of people who like & use Openbox nowadays, maybe you would like to give it a try.

spartrekus · 2017-06-02 20:03:47

FOSSuser wrote:

If I remember, I switched to Fluxbox because it wasn't being maintained, but there are a lot of people who like & use Openbox nowadays, maybe you would like to give it a try.

With Linux, it is always the same. When a software is good, stable, efficiently ugly and having low memory footprint, the project will be abandoned.
Always same story

I will miss blackbox when Wayland will come up !

greenjeans · 2017-06-02 21:02:53

spartrekus wrote:

FOSSuser wrote:
If I remember, I switched to Fluxbox because it wasn't being maintained, but there are a lot of people who like & use Openbox nowadays, maybe you would like to give it a try.
With Linux, it is always the same. When a software is good, stable, efficiently ugly and having low memory footprint, the project will be abandoned.
Always same story

Isn't that the dang truth? Ya know people were telling me like 6 years ago or so to stop using gpicview and use something else because gpicview was no longer being developed.

6 years later and it STILL WORKS JUST FINE.

It is no longer developed because THERE WAS NOTHING LEFT TO DO because IT WORKS JUST FREAKIN FINE WITHOUT ANY MORE CODE NEEDED!!

Not sure why this is so hard to understand for some folks. If it ain't broke, it don't need fixin', and if it don't need fixin', that means IT'S STABLE AND WORKS JUST FINE!!

In truth i'd be happy if almost EVERY package on my system was like this, I don't care how old they are or if they are being developed. Some end-users just mindlessly "upgrade" everything they can at every opportunity and spend waaaaaaay more time than I have to spare, trying to repair the resulting carnage.

spartrekus · 2017-06-02 21:43:28

greenjeans wrote:

spartrekus wrote:
FOSSuser wrote:
If I remember, I switched to Fluxbox because it wasn't being maintained, but there are a lot of people who like & use Openbox nowadays, maybe you would like to give it a try.
With Linux, it is always the same. When a software is good, stable, efficiently ugly and having low memory footprint, the project will be abandoned.
Always same story
Isn't that the dang truth? Ya know people were telling me like 6 years ago or so to stop using gpicview and use something else because gpicview was no longer being developed.
6 years later and it STILL WORKS JUST FINE.
It is no longer developed because THERE WAS NOTHING LEFT TO DO because IT WORKS JUST FREAKIN FINE WITHOUT ANY MORE CODE NEEDED!!
Not sure why this is so hard to understand for some folks. If it ain't broke, it don't need fixin', and if it don't need fixin', that means IT'S STABLE AND WORKS JUST FINE!!
In truth i'd be happy if almost EVERY package on my system was like this, I don't care how old they are or if they are being developed. Some end-users just mindlessly "upgrade" everything they can at every opportunity and spend waaaaaaay more time than I have to spare, trying to repair the resulting carnage.

For that MS Windows is more stable. You can mostly run an exe from win95 to win 7 without troubles.

Due to high complexity to compile outdated libraries with modern ones, under Linux, it is likely that a sofware without dev will die, since no one will compile it.
look for instance, siag is not longer on any linux repositories. Since it has old libraries, no want will make it available. The problem is that libraries are changing all the time under Linux. Since there are no standards to keep a graphical libraries or other under certain defined basic function, programmes without dev will simply die due to lack of compatiblity. Linux is moving too fast to be reliable. Furthermore, many applications are not written for efficiency, rather that it works, without considering memory and resource usage, which may slow down significanly a system.

The solution:
- Option 1: like on the cutting edge with bloated software
- Option 2: move to BSD where more concern is given.

If you have a superbe hardware, you won't worry about resource usage of your programme and how it performs.
E.g., If you have to drive 1h to reach a given town, and that you have 2-3 hours in front of you, you have quite a bit chance to take these 2-3 hours to procastinate or to start to drive at the last minute. On projects, 60-70% of persons will start to work on a given project the day before the deadline. Very few start to work 2-3 weeks before.

Last edited by spartrekus (2017-06-02 21:45:07)

malinas · 2017-06-02 21:53:06

spartrekus wrote:

Compiling didn't work much actually.

Image.cc: In member function 'void bt::Image::hgradient(const bt::Color&, const bt::Color&, bool)':
Image.cc:1350:42: error: 'memcpy' was not declared in this scope
       memcpy(p, data, width * sizeof(RGB));
                                          ^

For the record, this is because GCC got stricter over time about including C headers. If you download blackbox_0.70.1-34.debian.tar.xz from a mirror and uncompress it, you'll find a list of patches, among which fix-ftbfs-gcc-4.3.diff which adds the missing #include directives. The problems will only start if the package ends up orphaned.

spartrekus · 2017-06-02 22:05:09

malinas wrote:

spartrekus wrote:
Compiling didn't work much actually.
Image.cc: In member function 'void bt::Image::hgradient(const bt::Color&, const bt::Color&, bool)':
Image.cc:1350:42: error: 'memcpy' was not declared in this scope
       memcpy(p, data, width * sizeof(RGB));
                                          ^
For the record, this is because GCC got stricter over time about including C headers. If you download blackbox_0.70.1-34.debian.tar.xz from a mirror and uncompress it, you'll find a list of patches, among which fix-ftbfs-gcc-4.3.diff which adds the missing #include directives. The problems will only start if the package ends up orphaned.

it only depends on the code ! Let's take some codes... I am not so sure that the code couldn't be made more performant, with less include.

== 1. Cool
- dwm : is the cleanest code ever https://github.com/chjj/dwm/blob/master/dwm.c
- evilwm is really clean
- almost, pure beauty: http://download.tuxfamily.org/hatari/1. … .0.tar.bz2 except cmake.
- is this code https://fossies.org/linux/misc/old/uae-0.8.29.tar.gz cool?

== 2. Less Cool
- Less cool now?
- gtk?
- kde?
- make
- the new, modern, Xorg
- Is actually the code source of busybox like it should be?
- xbindkeys: http://hocwp.free.fr/ <- code available , not that great
- ndzen2, not that great either

== 3. Not good
- best, are bibtex, or many X11 applications.
- cmake
- mplayer is not that great

Ok, let's take this example:
Check the code of VIM, do you really like it?

Last edited by spartrekus (2017-06-02 22:36:00)

spartrekus · 2017-06-04 10:27:17

Why Blackbox be a WM that will die in some 5-10 years?

I believe that probably since no dev is being given. It is really pitty since it is really doing its job WELL and wihtout 50 mb of ram use.

stario 3212 0.0 0.3 12160 7208 tty2 S Jun03 0:00 blackbox

Nate · 2017-06-04 16:11:22

So you like Blackbox and, as pointed out above, patches are available to enable building on the current stable version. Pick up the maintenance! It's not hard. It's nice if you contact the previous maintainer/developer and request permission to do so, but it is by no means necessary under the terms of GPL, etc. Get it to build and then host your branch/fork/whatever on GitHub or some other site and just keep up with the changes as they come along.

By doing so you'll learn to get the most out of your Linux box and help the community.

spartrekus · 2017-06-05 06:20:22

Nate wrote:

So you like Blackbox and, as pointed out above, patches are available to enable building on the current stable version. Pick up the maintenance! It's not hard. It's nice if you contact the previous maintainer/developer and request permission to do so, but it is by no means necessary under the terms of GPL, etc. Get it to build and then host your branch/fork/whatever on GitHub or some other site and just keep up with the changes as they come along.
By doing so you'll learn to get the most out of your Linux box and help the community.

"Pick up the maintenance!  It's not hard."

It is not hard I can buy a pendrive and start this pendrive with DEVUAN Testing.

I installed the bunch of libraries that the source code of BB needs. OK. I can do that. What next? What do you need so that this compiled thing is being kept into the maintenance.

Important:
OK, I have found some bugs. I have corrected 2-3 bugs, and it goes better. And, now, compiling is better. I can compile it now to most of it.

Still there is an error into Util.cc
Could someone help me?

herewith the new version but Util.cc is holding my G++ to compile....
https://github.com/spartrekus/blackbox-0.70.2-bugfix

[u]Util.cc:209:85: error: 'std::string bt::textPropertyToString(Display*, XTextProperty&)' should have been declared inside 'bt'
 std::string  bt::textPropertyToString(::Display *display, ::XTextProperty& text_prop) 
                                                                                     ^
Makefile:374: recipe for target 'Util.lo' failed
make[2]: *** [Util.lo] Error 1
[/u]

Last edited by spartrekus (2017-06-05 07:18:20)

msi · 2017-06-05 17:31:25

If this is really just about finding a lightweight and stable window manager to use, I suggest that you take a good look at Openbox (or Fluxbox) before investing time in fixing bugs in a piece of software that apparently hasn't really been maintained for over a decade. Openbox etc. also are surely used much more widely than Blackbox these days, which means that they get a lot more testing and feedback.

If you should find Openbox useful, there's also some packaging work for Devuan to be done: Back in Debian Wheezy there used to be a package openbox-themes in the repositories which was later dropped. I've recently installed that package on Devuan Jessie and it worked just fine. So, I think it should be easy to re-package that for Devuan, including some additional themes.

If you're still interested in hacking Blackbox, you might want to have a look at https://github.com/bbidulock/blackboxwm.

spartrekus · 2017-06-05 19:14:19

msi wrote:

If this is really just about finding a lightweight and stable window manager to use, I suggest that you take a good look at Openbox (or Fluxbox) before investing time in fixing bugs in a piece of software that apparently hasn't really been maintained for over a decade. Openbox etc. also are surely used much more widely than Blackbox these days, which means that they get a lot more testing and feedback.
If you should find Openbox useful, there's also some packaging work for Devuan to be done: Back in Debian Wheezy there used to be a package openbox-themes in the repositories which was later dropped. I've recently installed that package on Devuan Jessie and it worked just fine. So, I think it should be easy to re-package that for Devuan, including some additional themes.
If you're still interested in hacking Blackbox, you might want to have a look at https://github.com/bbidulock/blackboxwm.

I pretty much prefer Blackbox to Openbox. I don't know why.
Blackbox is really nice. It is too easy to understand for everyone, and besides blackbox is not using XML.

Oh...why Blackbox. Just because it takes much less memory than Openbox. Memory usage is my first consideration in the choice.
I remember that tinywm is less than 50 lines, and it takes nothing. So shall another WM:

Well, you won't sell me Openbox, so far, I but well, if Openbox might reduce the use of Memory, maybe, it could be good.

DWM is pretty small in use of space. Evilwm too.

But blackbox offers almost everything one may need and its size is tiny.

msi · 2017-06-05 19:40:24

spartrekus wrote:

Memory usage is my first consideration in the choice.

Ok, then maybe you'll find some interest in JWM: http://joewing.net/projects/jwm

smoki · 2017-06-05 19:53:57

spartrekus wrote:

Well, you won't sell me Openbox, so far, I but well, if Openbox might reduce the use of Memory, maybe, it could be good.

You can make Openbox more tiny too, when compile disable all optional features at configure time and it would use something like 3 times less memory

Last edited by smoki (2017-06-05 19:54:47)

spartrekus · 2017-06-05 20:20:04

msi wrote:

spartrekus wrote:
Memory usage is my first consideration in the choice.
Ok, then maybe you'll find some interest in JWM: http://joewing.net/projects/jwm

I would be interested to compare the mem usage of JWM versus Blackbox.

Blackbox remembers me fluxbox, in a tiny way.
my users like blackbox.

smoki · 2017-06-05 20:31:56

spartrekus wrote:

I would be interested to compare the mem usage of JWM versus Blackbox.

Debian packaged jwm on 32bit uses about 500 KB uncached, blackbox about 800 KB, openbox about 3500 KB... but it have more features enabled since it mainly serve LXDE as i said you can take that down to 1200 KB easely or so

Of course, if anyone care about that range of sizes these days he might look at other distros, doing static and other special embeded builds or so.. on the other side general purpose builds (what major distros do) and computing tends to be more bloated, more features and more deps and particualary more dynamic also means more cached memory used, probably less long term compatability of that build... and so on

Last edited by smoki (2017-06-05 21:00:58)

spartrekus · 2017-06-05 21:02:11

smoki wrote:

spartrekus wrote:
I would be interested to compare the mem usage of JWM versus Blackbox.
Debian packaged jwm on 32bit uses about 500 KB uncached, blackbox about 800 KB, openbox about 3500 KB... but it have more features enabled since it mainly serve LXDE as i said you can take that down to 1200 KB easely or so
Of course, if anyone care about that range of sizes these days he might look at other distros, doing static and other special embeded builds or so.. on the other side general purpose builds (what major distros do) and computing tends to be more bloated, more features and more deps also means more cached memory used and so on

jwm is ok, openbox too.
Something like Blackbox would be ok, anyhow, it can still be compiled if... fixed, and be used on libx11-dev.

my installation is on nothing to save space and resource.

     apt-get update ;  apt-get install ntpdate  links w3m ncftp  netbase wpasupplicant  make  gcc bc subversion  gcc bc ncurses-dev      
     apt-get install    nedit  scrot   xinit libx11-dev blackbox menu      xserver-xorg alsa-utils alsa-base  ssh 
     apt-get install screen openssh-server           
     and chromium

By the time, it goes to less than less... I want to compile the kernel and have my own compiler and system, based on Linux kernel. I have time, I am learning step by step.
https://github.com/spartrekus/tinybox

Last edited by spartrekus (2017-06-05 21:07:51)

smoki · 2017-06-05 22:05:50

spartrekus wrote:

I want to compile the kernel and have my own compiler and system, based on Linux kernel.

Ah thinkering about something is cool so that is cool, i just expect this 'Support>Desktop and Multimedia' forum would be about Devuan and not about something else.

Even deb packaged blackbox in Devuan i now tried works fine here and recompile fine too, so And of course thing easely goes offtopic because it is offtopic in the first place

Last edited by smoki (2017-06-05 22:11:10)

spartrekus · 2017-06-06 04:51:43

smoki wrote:

spartrekus wrote:
I want to compile the kernel and have my own compiler and system, based on Linux kernel.
Ah thinkering about something is cool so that is cool, i just expect this 'Support>Desktop and Multimedia' forum would be about Devuan and not about something else.
Even deb packaged blackbox in Devuan i now tried works fine here and recompile fine too, so And of course thing easely goes offtopic because it is offtopic in the first place

Anyhow, we do some philosophy,...

Maybe this thread shall go/move to off-topic section.

golinux · 2017-06-06 14:06:08

Moved as requested . . .

spartrekus · 2017-06-06 21:38:35

golinux wrote:

Moved as requested . . .

Merci

spartrekus · 2017-06-08 05:46:37

On my system, I figure out a bit memory usage in general. herewith indicated.
Blackbox is really light.

Furthermore, I have impression that Blackbox runs extremely fast. It is very quick, new windows popup immediately, in a flash.
Openbox is too but it looks a bit slower.
Icewm is less fast.
Just first reaction time impressions.

MEM 244/1844MB]

KiB Mem:   1889204 total,   797888 used,  1091316 free,    47784 buffers

  PID USER    PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
 3356 root        20   0  133420  70040  15944 S   1.7  3.7   7:47.99 Xorg
                          20   0  568940 130632 100608 S   0.3  6.9   0:06.88 chromium

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 3366 sparrot    20   0 [b]12156  7468  6428 [/b]S  0.0  0.4  0:00.94 blackbox

Last edited by spartrekus (2017-06-08 05:47:00)

spartrekus · 2017-06-11 12:30:28

Blackbox is so fast !

After days of emperimentig X11 Window Manager, it is clear that Blackbox is faster than Openbox..
It seems that it has all what users may need of.

The question is that JWM takes more memory than Blackbox.
Blackbox looks nicer than JWM in my opinion

Users can do something with it since there is a menu for changing options, embedeed.

fungus · 2017-07-13 09:29:20

Good to find you all, first note here.

I was recently sold to the idea of trying i3, with claims of being able to do it all and with minimal resources.
It is very different, it comes with a good manual but it may take some time to get used to. So keep a hardcopy of the manual next to the keyboard and a reading light, if you are like me and work in the dark with a dark desktop

Ram this days is relatively cheap, even for the poor like me. Cheap enough to stay with openbox and the occassional fun day with lxde.

PS In my non-systemd escapade I tried a FreeBsd TrueOS installation last night. I finally gave up waiting and went to sleep. This is like taking a leap to 2 decades back. Absolute crap and waste of time. Sorry BSD folks!

msi · 2017-07-13 13:39:07

fungus wrote:

PS In my non-systemd escapade I tried a FreeBsd TrueOS installation last night. I finally gave up waiting and went to sleep. This is like taking a leap to 2 decades back. Absolute crap and waste of time.

Instead of merely insulting FreeBSD/TrueOS, could you (in a new thread) provide reasons for why you think using these systems is "like taking a leap to 2 decades back" and a waste of time? I would be very much interested, since I've recently tried FreeBSD (but not TrueOS) and taken some notes about my experience.

The officially official Devuan Forum!

#1 2017-05-31 19:30:53

Is Blackbox still today a recommended or outdated WM ?

#2 2017-06-01 09:06:53

Re: Is Blackbox still today a recommended or outdated WM ?

#3 2017-06-02 20:03:47

Re: Is Blackbox still today a recommended or outdated WM ?

#4 2017-06-02 21:02:53

Re: Is Blackbox still today a recommended or outdated WM ?

#5 2017-06-02 21:43:28

Re: Is Blackbox still today a recommended or outdated WM ?

#6 2017-06-02 21:53:06

Re: Is Blackbox still today a recommended or outdated WM ?

#7 2017-06-02 22:05:09

Re: Is Blackbox still today a recommended or outdated WM ?

#8 2017-06-04 10:27:17

Re: Is Blackbox still today a recommended or outdated WM ?

#9 2017-06-04 16:11:22

Re: Is Blackbox still today a recommended or outdated WM ?

#10 2017-06-05 06:20:22

Re: Is Blackbox still today a recommended or outdated WM ?

#11 2017-06-05 17:31:25

Re: Is Blackbox still today a recommended or outdated WM ?

#12 2017-06-05 19:14:19

Re: Is Blackbox still today a recommended or outdated WM ?

#13 2017-06-05 19:40:24

Re: Is Blackbox still today a recommended or outdated WM ?

#14 2017-06-05 19:53:57

Re: Is Blackbox still today a recommended or outdated WM ?

#15 2017-06-05 20:20:04

Re: Is Blackbox still today a recommended or outdated WM ?

#16 2017-06-05 20:31:56

Re: Is Blackbox still today a recommended or outdated WM ?

#17 2017-06-05 21:02:11

Re: Is Blackbox still today a recommended or outdated WM ?

#18 2017-06-05 22:05:50

Re: Is Blackbox still today a recommended or outdated WM ?

#19 2017-06-06 04:51:43

Re: Is Blackbox still today a recommended or outdated WM ?

#20 2017-06-06 14:06:08

Re: Is Blackbox still today a recommended or outdated WM ?

#21 2017-06-06 21:38:35

Re: Is Blackbox still today a recommended or outdated WM ?

#22 2017-06-08 05:46:37

Re: Is Blackbox still today a recommended or outdated WM ?

#23 2017-06-11 12:30:28

Re: Is Blackbox still today a recommended or outdated WM ?

#24 2017-07-13 09:29:20

Re: Is Blackbox still today a recommended or outdated WM ?

#25 2017-07-13 13:39:07

Re: Is Blackbox still today a recommended or outdated WM ?

Board footer