This poll will run for 1 week from now.
Afterwards, I'll set a milestone on github and call for a feature-freeze until we have reached that milestone.
All of these features will be implemented in blackbox.
However, only the top 7 voted features will be implemented in the next stable release of bbZero - the rest will follow in later releases.
So please vote for the features which you really want to see in the next release.
The following is a description of the features with rough time estimations. I hope I included everything. If not, my bad
Note: the order of the items is randomized to make them less biased.
1 Graphics: Layered Windows (more transparency control)
Short
Separate transparent layers on stylable items
Time esitmation
~10 hours for the basic implementation
~8 hours for corner cases
Long
Currently the only option for alpha transparency in blackbox is to set the alpha value of a full window (see picture 1).
Picture 1 - Menu alpha 1.7.png 28.17KB 2 downloads
With layered windows, it would be possible to set the alpha value for single items separately.
For example, you will be able to set a 10% yellow-blue gradient as the background of your menu and a 100% black foreground for text.
Or you could set a 40% black menu background with 100% gray foreground (see picture 2).
Picture 2 - Menu alpha 1.9.png 28.1KB 0 downloads
If we take it further, we can extend the idea to have separate alpha values for individual items which are drawn atop each other (Menu bg/Menu title bg/Menu title fg or Toolbar bg/Toolbar button bg/Toolbar button fg).
2 Dev: 64bit MinGW support, Eclipse support
Short
Better support for the open source development tools using MinGW as a toolchain and Eclipse as IDE.
Time estimation
~10 hours to fix current issues
1-2 weeks of use to identify and fix issues
Long
The current cmake-based build system is still a little rough around the edges.
For Visual Studio, which is what most of our developers use, it works very well, but for MinGW and Eclipse it works with restrictions and/or is just not tested.
However, as we want to encourage people to contribute source code (and fix the bugs we work so hard on to produce), we will give the open source toolchains some attention.
This basically means using MinGW and Eclipse exclusively for a week or two and fixing all the build-related problems which occur.
3 Plugin bbKeys: Mouse bindings
Short
Mouse bindings to manipulate windows like *nix window managers.
Time estimation
~8 hours
Long
In a typical stacking *nix window manager, it is possible to move and resize windows by clicking anywhere on them while holding a modifier key.
This is extremely useful if you often move windows around or resize them often, as you do not have to click the title bar or the resize grips - instead, you can click anywhere in the window.
A typical configuration would be:
[*]Ctrl + LMB - Move window
[*]Ctrl + RMB - Resize window
[/list]
There are third party tools which do this, but it would be nice if we could integrate the functionality into bbKeys.
Fluxbox implements this feature (see http://fluxbox-wiki....board_shortcuts)
4 Core: bro@m event system
Short
Sends a bro@m when an event happens
Time estimation
~16 hours for a proof-of-concept
~40 hours to stabilize pattern matching and guards
~20 hours to add useful bro@ms
Long
Generally, event-based programming has proven to be very useful to declaratively create workflows.
In a configuration file, you specify how bb should react when a certain event occurs.
For example, you could write
?@Window.OnWorkspaceChanged(ws: ws == 2, window): @MakeSticky $window
and the effect would be that whenever a window is moved to workspace 2, it will be made sticky.
The syntax is still pending, but if we include pattern matching, guards and variables, it would be very powerful.
More examples :
# Upon right click on root window, show root menu?@RootWindow.OnClick("rmb", _, _, _, _): @ShowMenu -key root# Upon left click on root window, if it is within 50 pixels from the left edge,# use the previous background picture?@RootWindow.OnClick("lmb", dxl: dxl < 50, _, _, _): @PrevBackground# Upon left click on root window, if it is within 50 pixels from the right edge,# use the previous background picture?@RootWindow.OnClick("lmb", _, _, dxr: dxr < 50, _): @NextBackground
5 ???: Unicorn mode
Short
You know that you want this.
Time estimation
~69 hours
Long
[*]
[*]Implement Unicorn mode
[*]???
[*]Profit
[/list]
6 Plugin bbInterface: Overhaul
Short
Upgrade bbInterface with modern features, flexible layouts and bbZero graphical capabilities.
Time estimation
~12 hours for the first part
~20 hours for the second part
~32 hours for the third part
Long
bbInterface is an incredibly powerful plugin which allows to create user interfaces conveniently using the mouse.
With a few modifications we can bring it to the year 2014 with the features one would expect.
Currently, bbInterface_iTunes includes support for iTunes cover art.
The first part of the overhaul will extend this to include WinAmp cover art.
Also, it is hard to create layouts which work with multiple monitor resolutions.
The second part of the overhaul includes symbolic positions (ex.: frame.x: right) and flexible sizes (ex.: frame.width: 10%).
The third part of the overhaul will focus on upgrading the grpahical cpabilities of bbInterface.
This entails proper transparency-related features for images and support for the new gradient and drop shadow features in bbZero.
Unfortunately, bbInterface has a large code base. A quick glance shows that it probably has more code than bbZero's core.
7 Plugin bbLua: Overhaul
Short
Full API bindings for bbLua.
Time estimation
~12 hours to get basic API functions bound
~52 hours to get the full API into lua
Long
Lua is a very handy scripting language. It is simple, fast, easy to integrate and widely adopted (popular examples: conky, the *nix wm awesome, World of Warcraft and soon Wikipedia's markup).
Currently, bbLua is a proof-of-concept. It works, but has only a few bindings for the blackbox API.
With the overhaul, we would lift it to become a pluginloader which loads lua plugins.
I firmly believe that lua will provide a great opportunity for writing plugins.
It has a beautiful readable syntax and would allow testing ideas without the long build cycle which compiled plugins must go through.
Also it would allow us to create workarounds for bugs or missing features.
Since lua is easier to learn than C++ and you are less likely to break everything, this hopefully means we lazy core developers can offload some of the work to the community.
8 Pluginloader: 32bit WowAdapter
Short
Load 32bit plugins in 64bit blackbox.
Time estimation
~8 hours
Long
On 64bit Windows, it is impossible to load a 32bit dll into a 64bit process or vice-versa.
However, 64bit processes and 32bit processes can communicate with each other if they are designed for it.
The 32bit WowAdapter (Wow: 32bit windows on 64bit windows) is composed of
[*]a 64bit pluginloader which is loaded into the 64bit blackbox process and
[*]a 32bit process (the pluginhost) which loads 32bit pluginloader and plugin dlls
[/list]
In the proposed implementation, there are 2 communication channels:
[*]The control channel, which is used to send Load/Unload instructions from the 64bit pluginloader to the 32bit pluginhost
[*]The api channel, which is used to send API calls from 32bit plugins through the 32bit pluginhost to the 64bit pluginloader, which forwards them to the 64bit blackbox and returns the result the other way around
[/list]
The skeleton of this design is already implemented, but the actual API wrappers still require some work.
Especially out-style pointer parameters still cause me some headaches.
9 OS: Windows 8 support
Short
Feature-complete support for Windows 8.
Time estimation
~2 weeks of continuous use
~20 hours of fixing problems
Long
Most of us cling to Windows XP or Windows 7.
Those of us who are forced to use Windows 8 currently face an unsatisfactory blackbox experience.
Which is unfortunate, since Windows 8's shell is a big pile of poo and blackbox has provided consistent awesomeness for almost all major windows versions since 98.
Since mojmir has downgraded, none of the developers had the pleasure of being confined to Windows 8, so we focused our attention elsewhere.
However, now you have the opportunity to force us into coercion and fix Windows 8's "features".
This goal entails reported Windows 8-related issues plus developer confinement to Windows 8 for a few weeks.
10 Typeahead on menu
Short
Typeahead is a feature, in which you start typing a word and the system finds the first occurence of that word.
Time estimation
~12 hours
Long
(abridged from Source: http://fluxbox-wiki....title=Typeahead)
You open a menu and start typing the item you want, let's say "Applications".
You should see the word(s) getting underlined.
If there is multiple items with same kind of name, you can switch between them by pressing tab. Shift + tab goes other way around.
If you mistype a word, backspace erases characters back to where it matches other items.When pressing backspace with no selection (nothing underlined) the current submenu gets closed.
Enter opens a submenu or executes the item/application selected.
11 VWM: Workspace overhaul
Short
Make workspaces more usable and generally bring them closer to how they work on *nix.
Time estimation
~20 hours
Long
The current workspace model is unstable.
Sometimes when you switch a workspace, windows do not disappear and sometimes they disappear completely.
When a window steals focus it may or may not trigger a workspace switch and may or may not lead to window loss.
Workspaces have the potential to raise desktop productivity and could enable tiled window managing features.
However, with the current issues they are simply just frustrating.
We will investigate where these problems come from and create a workspace model which works as you expect it to work.
12 RC: Configs in user directories
Short
Use user directories as alternative storage location for configuration files.
Time estimation
~12 hours
Long
Blackbox works well as a portable application and is terrible for multi user environments and fails Windows Vista+' security model.
In Vista+, applications usually reside in %ProgramFiles% with all their applications read-only.
Applications read and write configuration data from and to the user directory.
With this change, we will support saving configuration files to the user directory (%ApplicationData%.blackbox)
using the same directory structure as the blackbox folder.
Most of the plugins search for their configuration files themselves, so to properly support this feature, we need to rewrite them to use the FindRCFile API function.
In FindRCFile we can then implement the following policy:
[*]
[*]If blackbox.noUserConfig is set to true, go to Step 3
[*]If the rc is in the user directory, use that. Done
[*]If the rc is in the blackbox directory, use that. Done
[*]If blackbox.noUserConfig is set to true, go to Step 6
[*]Create the rc file in the user directory, use that. Done
[*]Create the rc file in the blackbox directory, use that. Done
[/list]
To be able to enforce the old behavior for portable installations, blackbox always reads the noUserConfig value from the blackbox.rc file in the blackbox directory, if it exists.
13 Plugins/menus: make blocking operations asynchronous
Short
Prevent blackbox from hanging.
Time estimation
~25 hours
Long
There are a few operations in blackbox which are potentially long running. Examples:
[*]in bbleanbar, querying a window's icon
[*]loading icons in menus
[*]loading contents of folder menus
[/list]
Currently, when an application hangs, it can cause bb to hang (bbleanbar queries the application for it's icon, the application does not respond, bb waits forever for the icon and hangs itself).
Similarly, opening the submenu for 'Network' or mapped drives which are offline can cause a timeout during which bb hangs.
The same was true for menu icons until recently. bb would hang and menus would not pop up until icons were loaded.
Now they beautifully load asynchronously and the operation is abortable by selecting another menu.
14 Plugin bbZeroBar: merge bbLeanBar, bbLeanBar+, SystemBar and SystemBarEx
Short
Merge the best of every bar into a single modern implementation.
Time estimation
~48 hours
Long
Every bar has it's own features and shortcomings.
We will merge the features and fill in the shortcomings into a modern full featured implementation with maintainable, documented codebase.
15 Dev: Integrate a Unit testing framework
Short
Integrate an automated testing framework into our build and write unit tests.
Time estimation
~60 hours
Long
Unit testing will allow us to raise the quality of blackbox.
Automated test do not prove that an implementation is correct, but they can guarantee that it is devoid of defects.
Currently, we manually test whether features work as expected.
With unit tests, we can write short pieces of code which systematically check for problems.
This is especially helpful to check for regression bugs - things which worked before, but have been broken.
It is also helpful to show an overview of bugs and their status.