Usually RGBA BMPs aren't well understood, even for Windows, so not a big thing to worry. Probably not loading in-time makes it to display without transparency :-?

I understood you Siria, because RGBA BMPs, is also forgotten by image viewers. Is not very well known. Even Photoshop CS (CS 1) doesn't understand the background and makes it black, totally different as it does with APNG, even when you save it, it is transparent. It support saving but not importing.

Quote
JamesD
Is there an easy way to get the transparent pink into a bmp?

What do you mean? Just fill the areas you want transparent with magenta. The "cheaper" way, take MS Paint and do with the fill tool and the pencil after selecting magenta.

Not a big deal.

EDIT: by the way, where is documented the icon declaration for bars/menus?



Edited 1 time(s). Last edit at 11/03/2014 11:05PM by JohnHell.

Quote
siria
Wrong test ;-)

The Aura Skin does contain some buttons that appear black in my KM1.6+98se, and others that appear transparent, although in IrfanView ALL bmps look black.
There we have it: this can only mean some Aura buttons have partial transparency and some not.

Please upload a transparent .bmp (16x16) from the Aura Skin or any other transparent .bmp which you consider to be OK for tesing and I will post the result here.

Edit:
BTW, how do you explain that the same transparent .bmp which looks fine in the privbar shows up with black background in the toolbar set by macro?



Edited 1 time(s). Last edit at 11/03/2014 11:13PM by Yogi.

Yogi, your two screenshots definitely show *different* images. That proves nothing about the creating method. I'd suggest to just take your "black-macro-image" and insert exactly THIS via toolbars.cfg too for testing.

If you insist on an Aura pic, try from "mainbarCOLD" the home button, clock, cross, globe, reload, starlet, print. This is transparent even on win98, only the borders look like bitten.

Note that "mainbarDEAD" in the contrary shows black in win98 (but probably okay in newer systems). Anyway, on my old machine the "dead" state shows the gray version of the left-right arrows while a tab has no flip-back history yet. It turns green/cold when loading another link in the same tab.

@John, ah that could very well be the reason too of course! This awful RGBA/ARGB prob, have come across it in other tools already.
Not sure what you mean with "documentation"? A wiki or something? It sure is there described in detail, but if you only want to change something, look in menu Edit>Config>Toolbars and MenuIcons.

@James, I couldn't figure out what you mean, but if John assumes right, you're just not familiar yet with the whole magic pink system...? That simply means that there is NO really "transparent" color in a bmp at all. No alpha channel etc. Just plain colors. The trick is, that KM displays every pixel that is painted with the normal color "magenta" as transparent. It is one of the basic colors in my windows color picker palette, just take the most glaring pink

Quote
siria
@John, ah that could very well be the reason too of course! This awful RGBA/ARGB prob, have come across it in other tools already.
Not sure what you mean with "documentation"? A wiki or something? It sure is there described in detail, but if you only want to change something, look in menu Edit>Config>Toolbars and MenuIcons.

I thought you were talking about creating menus and "attaching" their icons with macros...

Nevermind

Quote
siria
Yogi, your two screenshots definitely show *different* images.

Of course there are two different images.
The first one is from the Aura skin with a transparent .bmp and the second one with a magic pink .bmp.

Quote
siria
I'd suggest to just take your "black-macro-image" and insert exactly THIS via toolbars.cfg too for testing.

Makes no sense to me. If inserted by toolbars.cfg it will probably render fine. All my transparent .BMPs are rendering fine in the privbar but not in the toolbar created by a macro. You can test yourself with the same macro I did. It is the Proxy2.kmm by desga2 which I have tried to use with transparent .BMPs.

Here we go with the suggested .BMPs on the toolbar created by macro:



As you can see, still with black background.

Okay, now that is much more convincing ;-)

The only prob is: it still does work transparent on MY machine!
Ah the mysteries of computers...
Perhaps some dll responsible for colors or whatever, no idea.
What system do you have? Surely a lot younger than mine...

Must admit I tried it not with proxy but my own macro, although I can't imagine that makes any difference. Probably just our different machines, but anyway, if you like test it also with the rebarmenu-test macro I posted just today in the bug forum.
Change the icon to:
$_icons = "mainbarcold.bmp[4]" ;
This does show up transparent here.

-------

But for my win98 color prob, figured out this by now:
Both mainbarcold (transp.) and mainbardead (black) are in RGBA format.

The "cold" has a black background, which is transparent. Opacity 0.
The "dead" has a dark-dark-dark-gray background, which is transparent on modern machines but not mine. Opacity also 0.
The privbar (showing up in win98 with transparent text on transparent background) also has a black background, opacity 0. The text is black also, opacity 255.

Ergo: The modern machines can display images with text in black+opac255 und background in black+opac0.
Mine only recognizes 1 single color as transparent. It thinks: the alpha channel is set on "black"? Okay, *everything* in black will be shown transparent

The "mainbardead" seems to also have somehow defined alpha-channel=black, but an additional, separate opacity value 0 for the dark-dark-gray background. It's not matching the alpha-channel color, so it's not shown transparent in win98.

Solution: the pics should be defined with another alpha-channel-color as black! Otherwise everything painted in black will show up transparent on older machines. It makes not much sense to me anyway, to use for transparency such a frequent color, are more rare one (like magenta ) causes less accidents. But of course any other color (incl. dark-dark-gray) works fine too, as long as it's also set as primary alpha-channel-color, instead of "alpha=black"

PS: this is just informational. It's not my own problem, since I'm using another skin anyway.



Edited 2 time(s). Last edit at 11/04/2014 02:08AM by siria.

Quote
siria
What system do you have?

As mentioned a couple of posts above, Win7. As far as I can remember transparent .BMP wasn't supported on toolbars set by macro in W2K neither.

Quote
siria
Must admit I tried it not with proxy but my own macro, although I can't imagine that makes any difference.

You don't need to set up a proxy in order to test that .kmm but you are right, it is irrelevant which .kmm you take for testing.

Quote
siria
but anyway, if you like test it also with the rebarmenu-test macro I posted just today in the bug forum.

I am no test-maniac but since I assume that you would like to see how it looks on Win7, here we go:

Quote
siria
PS: this is just informational. It's not my own problem, since I'm using another skin anyway.

The fact that transparent .bmp on toolbars set by macro isn't supported is neither a problem for me. I just mentioned it since we were talking about transparent .bmp support in KM.

Thanks for testing, so this rules out any macro syntax details too.

But still the transparency IS supported for macro-created buttons too - just not on *your* machine. That's too weird, that it works on my age old machine and not on yours! What in the world is blocking it on yours??? Any setting? Any system stuff? Not the slightest idea.

Anyone else out there? Does it work for you? Or not?

I can't test as I can't create a toolbar :-? even using the JamesD code in the first page (because I didn't trust in my own try). No way.

But... this helped to find and amazingly stupid bug with the toolbars and the K-meleon 74 window:

kmeleonmovewindowbug.7z

Click and hold in the empty space left by a toolbar (can be even in the tiny space between 2 toolbars) at its right, move the window and have fun. Happens even maximized...

Confirm this to post to bug tracker. It happended in Windows 2000 and XP SP2.



Edited 2 time(s). Last edit at 11/04/2014 10:08PM by JohnHell.

Quote
siria
But still the transparency IS supported for macro-created buttons too - just not on *your* machine. That's too weird, that it works on my age old machine and not on yours! What in the world is blocking it on yours??? Any setting? Any system stuff?

I'm afraid it's not only "my" machine.

Quote
rodocop
Alpha-transparency IS supported from sometime,

BUT

only for toolbars, produced by toolbars.cfg.

As for system settings, I would say they are irrelevant for this case.
BTW, I don't think that we both have the same system configuration.

The same applies for browser settings. However, anybody can test with a clean profile.

Quote
JohnHell
But... this helped to find and amazingly stupid bug with the toolbars and the K-meleon 74 window:

kmeleonmovewindowbug.7z

Click and hold in the empty space left by a toolbar (can be even in the tiny space between 2 toolbars) at its right, move the window and have fun. Happens even maximized...

Confirm this to post to bug tracker. It happended in Windows 2000 and XP SP2.

That .7z brings up a Mediafire page, and when I used DLExpert to get the file, it turns out to be password-protected.


I was quite surprised when I found the bug back in 2011, see http://kmeleonbrowser.org/forum/read.php?3,116588,116588#msg-116588. I couldn't quite bring myself to insist the bug be removed And then to find it on KM74 :cool:

But it seems not quite to be a bug: http://kmeleonbrowser.org/forum/read.php?1,103035,103257#msg-103257 from 2010...

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

Quote
gordon451

Quote
JohnHell
kmeleonmovewindowbug.7z

Click and hold in the empty space left by a toolbar (can be even in the tiny space between 2 toolbars) at its right, move the window and have fun. Happens even maximized...

Confirm this to post to bug tracker. It happended in Windows 2000 and XP SP2.

That .7z brings up a Mediafire page, and when I used DLExpert to get the file, it turns out to be password-protected.

Works for me in any browser :-?. It hasn't any password protection.

Unless MediaFire ads tricked you...

Quote
gordon451
I was quite surprised when I found the bug back in 2011, see http://kmeleonbrowser.org/forum/read.php?3,116588,116588#msg-116588. I couldn't quite bring myself to insist the bug be removed And then to find it on KM74 :cool:

But it seems not quite to be a bug: http://kmeleonbrowser.org/forum/read.php?1,103035,103257#msg-103257 from 2010...

Gordon.

But that is not a fix or a feature but an extension/added feature.

Or am I wrong?

Anyway, ok, I won't report as a bug


Still unable to create a toolbar and a button in that toolbar with a macro. Any example macro? Even without errors I might be doing something wrong.

Try with the rebarmenu test macro, it creates buttons too ;-)
You'll have to make sure to pick a black pic from the Aura mainbarCOLD for the test, but I trust that's no prob for you
Since the macro was originally written to only test menu checkmarks, the default pic is hotlist.bmp, but I'm afraid that's one of those with nightgray background color but black alphachannel in Aura. Not sure, but better change icon to mainbarcold, that definitely has the same background color as defined in the alphachannel. In other systems it doesn't seem to matter, but win98 can only show transparency if the colors are the same.

download:
http://kmeleonbrowser.org/forum/file.php?9,file=929,filename=rebarmenu_test.kmm

rebarmenu thread (has nothing to do with transparency)
http://kmeleonbrowser.org/forum/read.php?3,130665



Edited 1 time(s). Last edit at 11/05/2014 12:44AM by siria.

Weird, in Windows 2000 it is transparent, in XP SP2 (virtual machine) it's black :mad:

I'll blame XP SP2 as it is a virtual machine and might not be playing fair, but RGBA BMPs in the toolbars work when aren't build with a macro.


EDIT: He, in Windows 7 (virtual machine) is white (custom theme involved, I guess)



Edited 2 time(s). Last edit at 11/05/2014 01:36AM by JohnHell.

Crazy! So I take this as confirmation, KM supports transparent macro-buttons on old systems (win98+win2000), but newer systems fail, incl. win7! And it probably depends on the windows theme :O

Your multi-system test may very well be a key to solving that mystery.
Just for curiosity: What does your virtual win7 do with a multicolor-transparency button like those on Auras mainbarDEAD?? (1+1 = all others show those black)
(don't know the correct term, for a specific transparency grade possible on several different colors)

Quote
siria
Crazy! So I take this as confirmation, KM supports transparent macro-buttons on old systems (win98+win2000), but newer systems fail, incl. win7! And it probably depends on the windows theme :O

Your multi-system test may very well be a key to solving that mystery.
Just for curiosity: What does your virtual win7 do with a multicolor-transparency button like those on Auras mainbarDEAD?? (1+1 = all others show those black)
(don't know the correct term, for a specific transparency grade possible on several different colors)

It's the same. White background. If the graphic is this (note: postimg.org converts the bmp in png).

I even changed the theme and it was the same :-? But I didn't reboot (about 5 minutes in my humble PC)

I also tried the same version of gdiplus.dll I have in Windows 2000, just in case, and nothing.

But I point out again that they are virtual machines, with emulated hardware (MS Virtual PC 2004 virtualizes an S3 Virge graphic card) and that might change results. Who knows...

More people with actual hardware should test too.


EDIT: It is black, not white. I remembered that the virtual machines sets by default 16 bits instead 32 bits depth. In 16 bits was white background, and in 32 it is black in Windows 7.

In Windows 2000, doesn't matter 16 or 32. It is transparent. I had XP with 32 bits so no change either: black background.



Edited 3 time(s). Last edit at 11/05/2014 02:40PM by JohnHell.

Here a sample of what I may do. If you have any suggestions.
Toolbar and menu icons will be shared, in a way or another.

@ Dorian

I have the info, three files, but what do I do with it? I made a skin folder and put the files there, but no images show. There is a toolbar without a name, but it shows no images.

I need just a little more instruction please.

Isn't redundant the size definitions in the icons.cfg (what I guess is the equivalent of menuicons.cfg)?

Where/How in toolbars.cfg will be called to the image used? With a new "images":[{}] section?

@JamesD, I guess is for a new K-meleon.exe file as I don't expect the current to parse it.


P.S.: json, finally face to face



Edited 1 time(s). Last edit at 11/06/2014 02:25AM by JohnHell.

OK, not for actual use yet.

Will all the current skins become obsolete? What about the macros which make toolbars and buttons? Will custom bmp files need to be converted to png files. If the current bmp is a single image, will it need to be repeated so that it is a 1x3 array?

It looks like the png is an array. Do we assign the image to the button using the list in "icon.cfg"? Currently not all images are used. If we just match the order in the png file with the list in toolbars.cfg, how would one skip an image?

Can't figure it out... too complicated...
Same ??? as James and John...

Plus: riddling how would a user customize his buttons?
Which to hide or show, how rearrange the order... ?
How to mix buttons from different image bars into same toolbar, and vice versa...?
if possible at all.... and if possible it still looks a *LOT* more complicated than today... *too* complicated.
Greatly missing the direct assignment of imagebar+number next to the command in toolbars.cfg...
would comment lines in toolbars.cfg still be possible or not...
Would it perhaps be possible that a user can choose using either the old toolbars.DLL and skin system or only the new...

And then of course I start wondering what for??
Would there be great enough advantages worth to nearly give up customizing...

Quote
JohnHell
It hasn't any password protection.

Unless MediaFire ads tricked you...

No... When the MediaFire page came up I killed it because I had not expected it, then realised I could use DLExpert to get it anyway. I was surprised because usually when I click on a non-executable or unknown MIMEtype K-M will download automatically. I figured MediaFire was interfering with my download. So, as the Daleks used to say: "Exterminate!"

It was only when I opened the file with PeaZip that PeaZip told me it needed a password.

Quote

But that is not a fix or a feature but an extension/added feature.

It does look like it was originally an extension/feature of some sort, that became forgotten.

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

It would be simpler if each button had a separate icon file.

And it would also allow us to hide any button we do not want which can be done on the mainbar with the current skin system.

You're confused because there is only one toolbar in my example, but both cfg are independent, so you're (nearly) not losing anything. I'll post something more complete later.

Quote
Dorian
You're confused because there is only one toolbar in my example, but both cfg are independent, so you're (nearly) not losing anything. I'll post something more complete later.

I am not confused. I thought having separate icon files for maibar buttons would easier that searching the whole mainbar.png for them

It would also would simolify macros for icons.cfg and toolbars.cfg that display the buttons for mainbar.

It appears that each column of buttons is identified by the "command" assigned to it in icons.cfg. The command is then matched to "action" in the file toolbars.cfg. What we would lose is the ability to use a button for anything other than its intended command or action.

In the case of Klassic skin the tool[hot,cold,dead].bmp[7] is reused for bookmarks(Edit), favorites(Edit), and hotlist(Edit). It seems likely that the [7] bmps column would need to be repeated twice for a total of three columns. Each column would be assigned a different command.

That is just my interpretation of what I have seen so far.

Wishing to agree with JohnHell and siria that truly customizing toolbar to me goes toward the smallest buttons available. siria can write my wishlist anytime.
Truly= Small buttons attracted me to k-meleon in the first impression years ago. A skin is only a skin if it fits upon (around) the prebuilt/ shared framework of browser. Is more toward persona was unlike theme. Standardizing is benefit to skin making. One say,,, gee Dorian what size did you have in mind? Possibly Your question is more to ear of designer; designers who have replied with their usual no problem are up to the sizable sizing task to accomodate your design. Yet i. voice interject as consumer. A skin that troubles to change button size should benefit itself by creating original icon picture as well, for notoriety and popularity, or to capture me with small buttons! Let the skin maker choose to do all that much work. (or make compatible with like barisderin' theme and font changer.)
Being enthusiast of small toolbar is insignificant in satisfying the future of browser. Even if to the extreme of no alteration to toolbar available i. must adhere to being proponent of larger buttons as default for the touchscreen thumbs, swipes, and fingers of the future of Windows. The default size must be viewable on a smartphone size screen and anticipated be enlarged to tap-able size on a tablet and expanded to a intolerable large screen-stealing size on a desktop. The larger size button is necessity. not a limitation. Standardization on larger sizes throughout Windows is a command performance/ necessity for survival; therefore must not be termed limitation. The button size is minimized around the default text . Dorian offers standard size without text; this not be the text in the privacy bar. How many buttons are in this textless category Dorian? being a Windows program should take k-meleon into glyphs. be the first to lose the toolbar. until then use the new standard for future Windows. it is big size. Have a skin developer make available desktop version for offer two distinct version one optimized for desktop one future standard for touch? settle for that? Possible you view just the other way around. That is in part why i. offer viewpoint. [@JamesD what about one standard size for top toolbar and one smaller size for bottom toolbar to customize place/ shift into either? that be just two to get started. high resolution is coming: phone is 48X48, so more of that for near future desktop is inevitable thanks to touch. The large icons in use of, my favorite, WinVista (i. know i. be distrait) is depleting. WinSeven now not available USA. Move on. Virtual WSeven on eight pluspointone is fantastic. look future. ten is near. of all the usual sizes; smaller soon obsolete.] A desktop k-meleon version that promises to make the desktop more powerful again (than a tablet for goodness sake) be same one that will fit Windows ten. Noble is Your use of the word limitation seems compassionately applied if to the limitations of some users' display equipment. Limitation aside then? Can developer be comfortable in focus on new standard making secondary the wish of customization? are skins that important? to developer? no. only default toolbar (top and bottom?) The goal of the end-user is quick identification, convenient placement. Whatever You want Dorian. Combined with the Microsoft demands of the future centrally important k-meleon browser. Find Your way to forge with joyful heart. Thank You. Respectfully ___i. ri.

will browser become resolution specific like phone? resolution-detect. set-scale?

Quote
JamesD
It appears that each column of buttons is identified by the "command" assigned to it in icons.cfg. The command is then matched to "action" in the file toolbars.cfg. What we would lose is the ability to use a button for anything other than its intended command or action.

In the case of Klassic skin the tool[hot,cold,dead].bmp[7] is reused for bookmarks(Edit), favorites(Edit), and hotlist(Edit). It seems likely that the [7] bmps column would need to be repeated twice for a total of three columns. Each column would be assigned a different command.

That is just my interpretation of what I have seen so far.

Good point, JamesD, I didn't see that.

But also have a look to icons.cfg again and you'll see that for some icons there are various commands per line (for home and bookmarks) between "[ ]".

So for your examaple would be:
["bookmarks(Edit)", "favorites(Edit)", "hotlist(Edit)"]

Still is not a very intuitive system, as json isn't intuitive (at least for me), but look nice in the other way... I'm looking it with other eyes.

What I still don't get, Dorian, is what has to do the statement of your first post about size with all of this:

Quote
Dorian
every toolbar in a skin will need to have the same size for the button images

The size of toolbars starts to mismatch in my head with size of the button images.

I'm starting to doubt what are you referring to size now. Number of icons?

Quote
JohnHell
But also have a look to icons.cfg again and you'll see that for some icons there are various commands per line (for home and bookmarks) between "[ ]".

So for your examaple would be:
["bookmarks(Edit)", "favorites(Edit)", "hotlist(Edit)"]

Good catch! I missed that. Oh, well, back to studying and pondering about how Klassic will look.

I also have to figure out how I will build a 3 by x array image where type is png. I have a new program that I need to load and try.