17 replies to this topic

[pitkon]

OK, so this is my wish list for future BB builds I put down some time ago and I expect to add to it from time to time. Some may think that some of the items may beat Blackbox's main purpose of simplicity and minimalism, but I am an eye-candy person who used Litestep from 1998 to 2001, so old habits are hard to break. And I am a style author, which means I'd like to have more and more tools at my disposal. Besides, as I say to anyone who objects, "Turn everything off, man, but the elements you wish to keep". That's another or Blackbox's peculiarities and strong points. My point is, if we don't keep rolling, we may gather some moss...

 

1)   Spherical elements (curved toolbar, menus etc.)

I think this is pretty obvious.

  2)   GFX files option for decorations (toolbar background, menu background, menu.title background, window skin background etc. a la Fluxbox/Openbox).

Hundreds of examples in Litestep configurations, where a graphic file serves as systembar/menu background. There was even an attempt to use bitmaps on Blackbox 2 (remember that one?) If not, I can post the build here. Even Fluxbox/Openbox can use bitmaps as backgrounds for various box elements. Keep in mind pixmaps.

 

3)   Gradient borders (border.appearance)

ALL gradients already used in BBClean XZ and other modern builds. (Split gradients, verticals, pyramid, pipecross, diagonal etc. – the works, with color/colorsplitto/colorto/colorsplitto options). I am expecting a border that would make frames (toolbar, menus, windows, bbi frames) look even better and with a clever combination of border and frame colors would radically change the look.

 

4)   Border shadow

A shadow around elements with borders,  same options as shadow.color and shadow y/x that will give the illusion of a 3-dimensional element. Thus, even systembar and menus can have shadows (actually, menus already have those). Windows can have shadows using apps like Y’Shadow, but now the shadow can be determined by the style file.

 

5)   Different font option for the toolbar elements (clock.font, label.font, window.label font)

Again, self-explanatory. The night build of Xoblite already has that, would like to see the feature on other builds, too.

 

6)   Bitmaps for toolbar arrows (toolbar.button)

Self-explanatory.

 

7)   Shadows and outline for toolbar arrows (if 6) is not applied)

Self-explanatory.

 

8)   Drop shadows for all box elements (toolbar, menus, windows etc.)

See 4) If a border is not used by the style author, box elements should still have the option to look 3 dimensional.

 

9)   Interlaced color defined (e.g. toolbar.interlace.color: blue)

Self-explanatory.

 

10)   Fully working menu grip, especially in the font/inscription/height departments...

XZero450 heeded my call (bless him) and included a menu.grip option in his latest (January 2012) build. This comes from an old Blackbox flavor called Lithium Desktop Environment (commercial, if you can believe it) by the Mouse People. For anyone who wants to see what this old build looked like, I can upload it here, it's been abandoned many years ago. The new menu grip is included in all my latest screenshots.  What I am looking for now is a fully working grip where you can determine font, inscription and height, not menu.title dependent. Think how great this would look if we could implement 2) and 3) as well. But this goes for all BB elements.

 

11)          More style commands/options

unkamunka (R.I.P.) added a “block” option for his latest Blackbox4Windows build. In short, it divided an element horizontally in two, using an individual color for each part. We had discussed, before he passed away, a diagonal version of this command, where the dividing line would extend from bottom left corner to top right corner and from bottom right corner to top left corner. And I’d like to see more options, bearing in mind the inherent BB limitations.

[XZero450]

1)   Spherical elements (curved toolbar, menus etc.)

I think this is pretty obvious.

 

 

This is possible using Windows' built in transparency that it compatible all the way back to Windows 2000, anything before and this wouldn't work. You would effectively lose 1 color as a result of doing this, and the entire gradient rendering process would have to be examined thoroughly and possibly rewritten to implement this.

 

3)   Gradient borders (border.appearance)

ALL gradients already used in BBClean XZ and other modern builds. (Split gradients, verticals, pyramid, pipecross, diagonal etc. – the works, with color/colorsplitto/colorto/colorsplitto options). I am expecting a border that would make frames (toolbar, menus, windows, bbi frames) look even better and with a clever combination of border and frame colors would radically change the look.

 

 

I remember saying I would look into this, but I wasn't sure if it was possible.

 

4)   Border shadow

A shadow around elements with borders,  same options as shadow.color and shadow y/x that will give the illusion of a 3-dimensional element. Thus, even systembar and menus can have shadows (actually, menus already have those). Windows can have shadows using apps like Y’Shadow, but now the shadow can be determined by the style file.

 

 

This one is confusing. Shadows for borders or shadows for various elements as defined in the style file?

 

5)   Different font option for the toolbar elements (clock.font, label.font, window.label font)

Again, self-explanatory. The night build of Xoblite already has that, would like to see the feature on other builds, too.

 

 

Easily do-able, toolbar plugins will likely have to be updated in order for this to work.

 

 

7)   Shadows and outline for toolbar arrows (if 6) is not applied)

Self-explanatory.

 

8)   Drop shadows for all box elements (toolbar, menus, windows etc.)

See 4) If a border is not used by the style author, box elements should still have the option to look 3 dimensional.

 

 

Once you've explained 6, explain how these are different.

 

9)   Interlaced color defined (e.g. toolbar.interlace.color: blue)

Self-explanatory.

 

 

While I'm messing around in the gradient code, again, I'll look into this. This bugged me for years that the interlace color wasn't definable, it should have been my number 2 fix.

 

10)   Fully working menu grip, especially in the font/inscription/height departments...

XZero450 heeded my call (bless him) and included a menu.grip option in his latest (January 2012) build. This comes from an old Blackbox flavor called Lithium Desktop Environment (commercial, if you can believe it) by the Mouse People. For anyone who wants to see what this old build looked like, I can upload it here, it's been abandoned many years ago. The new menu grip is included in all my latest screenshots.  What I am looking for now is a fully working grip where you can determine font, inscription and height, not menu.title dependent. Think how great this would look if we could implement 2) and 3) as well. But this goes for all BB elements.

 

 

When I implemented menu.grip it was purely a styling option. I would like it to be a lot more functional, meaning be another header type thing. [Insert more idea spew]. If diabol is going to pull the menu code out of the code, which I am not opposed to so long as plugins can access it more easily, then this should wait until that happens.

 

11)          More style commands/options

unkamunka (R.I.P.) added a “block” option for his latest Blackbox4Windows build. In short, it divided an element horizontally in two, using an individual color for each part. We had discussed, before he passed away, a diagonal version of this command, where the dividing line would extend from bottom left corner to top right corner and from bottom right corner to top left corner. And I’d like to see more options, bearing in mind the inherent BB limitations.

 

 

Pull out MS paint and start drawing example, and please also provide proper names for the new gradients. At this point we can pull in 4 colors, and any sort of pattern that can be created mathematically can be created in blackbox - you just have to keep in mind that we're still waiting to find the absolute last digit of pi.

[pitkon]

This is possible using Windows' built in transparency that it compatible all the way back to Windows 2000, anything before and this wouldn't work. You would effectively lose 1 color as a result of doing this, and the entire gradient rendering process would have to be examined thoroughly and possibly rewritten to implement this.

 

Can't see what spherical objects have to do with transparency, but you know best

 

I remember saying I would look into this, but I wasn't sure if it was possible.

 

 

This one is confusing. Shadows for borders or shadows for various elements as defined in the style file?

 

Drop shadows for elements like the toolbar and the windows.

 

 

Easily do-able, toolbar plugins will likely have to be updated in order for this to work.

 

 

Once you've explained 6, explain how these are different.

 

6: I thought it was clear. Bitmaps in the place of toolbar arrows, as in the menus.

If no bitmaps, than arrows < > should be able to have shadows.

8: I see it's about the same with 4, so scrap one of the two

 

 

While I'm messing around in the gradient code, again, I'll look into this. This bugged me for years that the interlace color wasn't definable, it should have been my number 2 fix.

 

It is definable in Fluxbox, if it's of any help...

 

 

When I implemented menu.grip it was purely a styling option. I would like it to be a lot more functional, meaning be another header type thing. [Insert more idea spew]. If diabol is going to pull the menu code out of the code, which I am not opposed to so long as plugins can access it more easily, then this should wait until that happens.

 

 

Pull out MS paint and start drawing example, and please also provide proper names for the new gradients. At this point we can pull in 4 colors, and any sort of pattern that can be created mathematically can be created in blackbox - you just have to keep in mind that we're still waiting to find the absolute last digit of pi.

 

You know what I am talking about. I mean according to your changelog you had implemented both block and wave on 1.17 (R.I.P.) As for proper names, I think we should keep block and wave out of respect for unkamunka. Now, 8-color gradients are a different thing. qwilk, in his latest test Xob build is using the simplest directives of them all, Color1, Color2, Color3 and Color4. What's even greater is that Color #1 is not Color#2, as it happens with ColorSplitTo (which should be Color1) and Color1 (which should be ColorSplitTo). I guess we can use the same simplicity with 8-colors, Color1 to Color8...

[diabol]

oh for fuck's sake,

if we do 8-color gradients, we might as well do m overlaid n-color gradients with variable splitter locations (from 0.0 to 1.0) and direction (angle)

or we could do pixel shaders (in lua or another sane language), which for a pixel (x,y) determine the (a,r,g,b ) value in a bounding box ((x0,y0), (x1,y1))

 

and i'm not even joking about this, the graphical capabilities are growing out of scope and i would like to get them back under control.

if we put them external to the core (except for the basic set of solids/gradients), we don't have to deal with this as much anymore.

 

also with more powerful gradients comes the cost of calculating them. it can easily get very expensive and bog down the system.

however, if we put this external to the core, we give users the ability to shoot their feet while keeping our hands clean

[pitkon]

oh for fuck's sake,

if we do 8-color gradients, we might as well do m overlaid n-color gradients with variable splitter locations (from 0.0 to 1.0) and direction (angle)

or we could do pixel shaders (in lua or another sane language), which for a pixel (x,y) determine the (a,r,g,b ) value in a bounding box ((x0,y0), (x1,y1))

 

and i'm not even joking about this, the graphical capabilities are growing out of scope and i would like to get them back under control.

if we put them external to the core (except for the basic set of solids/gradients), we don't have to deal with this as much anymore.

 

also with more powerful gradients comes the cost of calculating them. it can easily get very expensive and bog down the system.

however, if we put this external to the core, we give users the ability to shoot their feet while keeping our hands clean

LMAO, diabol...

Let's get the basics first, shall we? I mean let's keep everything XZero, you and moj have accomplished so far under one roof. No need for a hundred flavors, one with all the goodies is enough. 8-color gradients and what nots will follow, a step at a time. Wish qwilk was here, he used to say 8-color grads were no sweat. I have written him more than once but unfortunately he remains conspicuous by his absence...

[diabol]

yea, that's actually the kinda No. 0 point on my wishlist: more developers, especially more old developers :

[XZero450]

Before we address the 8 color issue we need to accomplish 2 primary things..

 

• Plugins need to be rewritten to request the "Gradient Engine Core" (note: I used the words 'Engine' and 'Core') to render their gradients in so that they no longer need to be recompiled to take advantage of additions.. Older plugins did a lot of this(SystemBarEx[My SystemBar, don't touch], as I recall) did this.
• We need to move the Gradient stuff outside of the Core(Blackbox.exe) so lesser systems are stuck with certain branches or something should we develop intensive gradients. We could essentially build multiple "Gradient Engine Core's" from the same code by running multiple build's and #DEFINE's .. Now this would be god awfully messy, but it's do-able.

 

In other news.. I executed blackbox.exe today, which was the first time in - well, before BlackboxZero was started.

[diabol]

seems like you are finally back in eat-your-own-dogfood land, xzero

[cthu1hu]

qwilk had anti-aliased rounded corners with apparently one line of code. He never released that build, but that would be my number one request.

[technorati]

I know it sounds counter intuitive to BB and possibly unwanted by many, but would it ever be possible to make it so that you can drag and drop icons onto the BB desktop? Like the windows desktop allows, or to have the system icons on the BB workspace? 

[diabol]

I know it sounds counter intuitive to BB and possibly unwanted by many, but would it ever be possible to make it so that you can drag and drop icons onto the BB desktop? Like the windows desktop allows, or to have the system icons on the BB workspace? 

 

There are plugins for that (bbDesktop), however I don't know what state they are in. Likely they'll need some tweaking

[technorati]

There are plugins for that (bbDesktop), however I don't know what state they are in. Likely they'll need some tweaking

I am using 64 bit version so there arent as many plugins I can use, but there is that one called "slit". It's a bit clunky though and kind of messes up my desktops hair style I will look for the desktop plugin 64bit  

[diabol]

uhh, maybe it's not yet included in the most recent build. moj added it recently to the code repository with a bunch of other plugins. kinda hard to keep track of all of them, but i'll be looking at bbdesktop the coming days

[cthu1hu]

I am using 64 bit version so there arent as many plugins I can use, but there is that one called "slit". It's a bit clunky though and kind of messes up my desktops hair style I will look for the desktop plugin 64bit  

You might mean bbIconBox. It's loaded in the slit in a lot of the default setups. The slit is just an invisible container. You can remove it from the slit and put it anywhere, but I get what you're saying about the aesthetics of your desktop. There used to be a version of bbIconBox with a fully transparent background. It still lingers, but the transparency no longer works; it displays as a black color now.

[4c2o]

Please add menu volume control like in that old version of bblean (I can't remember which). Or a taskbar plugin perhaps where you could just point with the mouse, no click required, and scroll the wheel up/down

[pitkon]

Please add menu volume control like in that old version of bblean (I can't remember which). Or a taskbar plugin perhaps where you could just point with the mouse, no click required, and scroll the wheel up/down

Volume control is included in all recent Blackbox builds. And can you please be more specific about what the pointer should do on the taskbar?

[m00k00]

Volume control is included in all recent Blackbox builds. And can you please be more specific about what the pointer should do on the taskbar?

 

I noticed that, however i cannot find an option to control the master volume always ... which is kind of bad for me, as i'm using three different sound devices depending on the screen i'm using (my two TVs feature sound via HDMI). I will also look into this ... as soon as i find some time

 

btw: sorry for digging up this kind of old thread again ... but i simply had to ... seeing you mention this problem i'm currently facing

[pitkon]

Please do dig up old threads. It's necessary for every next step