Quote
JamesD

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.

If you refer to a transparent .PNG like Dorian posted, IMHO that shouldn't be a problem. Freeware will do it.

I was able to make this image using XNVIEW.



Did I get the order, top to bottom, correct? It is going to be interesting to figure out what "command" is to be assigned to each image. Some of them no longer show in Klassic as I use it.

I want to try the privbar next, but which current bmp goes on top. There are two choices - green and red. That one would become a 2 by x png image?

For bookmarks, favorites, and hotlist I suppose I should make a 1 by x png image?

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 "[ ]".

Now that I look at it I can agree that it lacks readability if you're not used to it. I don't like XML and it's cumbersome to use but maybe this could be better. It would look like this:

<commandSet>
  <images>
    <image name="mainbar16.png" width="16" height="16" />
    <image name="mainbar24.png" width="24" height="24" />
  </images>
  <icons>
    <icon index="0" cmd="ID_NAV_BACK" />
    <icon index="1" cmd="ID_NAV_FORWARD" />
    ...
    <icon index="7" cmd="bookmarks(Add)" />
    <icon index="7" cmd="bookmarks(AddLink)" />
  </icons>  
</commandSet>
<commandSet>
 ...
</commandSet>

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

No, it's the icon size. Since the icons are shared, all buttons must have the same dimensions.

Quote
JamesD
For bookmarks, favorites, and hotlist I suppose I should make a 1 by x png image?

Hot and dead images are optionnal so that's fine.

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

Yeah, but don't expect it to run on phone :p

Quote
Dorian

<commandSet>
  <images>
    <image name="mainbar16.png" width="16" height="16" />
    <image name="mainbar24.png" width="24" height="24" />
  </images>
  <icons>
    <icon index="0" cmd="ID_NAV_BACK" />
    <icon index="1" cmd="ID_NAV_FORWARD" />
    ...
    <icon index="7" cmd="bookmarks(Add)" />
    <icon index="7" cmd="bookmarks(AddLink)" />
  </icons>  
</commandSet>
<commandSet>
 ...
</commandSet>

With index numbers it's certainly a bit better.
What I'm not quite sure yet: do you mean ALL icons in 1 skin, or perhaps (not much hope, considering privbar remark) merely ALL icons inside 1 toolbar?
But then, what's it with the blue mainbar lines with different sizes?
And what means "shared" - what's shared with what?
Menuicons with toolbar buttons? Both same size too?
Would "hidden" buttons be possible in a skin, that a user could simply unhide intuitively by removing #?

And in general: would there only be disadvantages or also any advantage over the current skin system?

Actually, I like the first method better than the XML method. Either one is different from our current design, so some learning will be required.

We would need to be able to have comments at the top each file and once the design is explained there, I think understanding will be more easy.

I think it would be easy to have an unused button. The buttons are identified by "commands" list so if the images in the 7th column did not have a command which exists, then those images are not called. For instance if the command for column 7 was "macros(Dummy)", and no macro with the name "Dummy" exists then column 7 images are unused.

I would just like to have verification that the image order in each column is Hot|Cold|Dead. Also what is to happen with columns which have less than three images. I took the order, Hot|Cold|Dead, from the pluginmsg(toolbars, "SetButtonImage" method. That seems at odds with how the system will handle images with only one row. Maybe it is Cold|Hot|Dead. My eyes are not so good anymore, and I cannot tell from the image Dorian posted.

I think I may see where Dorian is going with the requirement for same size. If I wanted a mail button from the mail/news toolbar to show in my main tool bar, I would just include its name, action, tip, and right action in the position I choose in the buttons list for my main tool bar.

Quote
JamesD
I think I may see where Dorian is going with the requirement for same size. If I wanted a mail button from the mail/news toolbar to show in my main tool bar, I would just include its name, action, tip, and right action in the position I choose in the buttons list for my main tool bar.

Basically that's how the current system works too, except it also has the icon defined right inside the buttons. For me that offers more flexibility and overview, but perhaps a matter of different tastes.

Dorians first example image has the first two rows looking identic.

Quote
Dorian

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 "[ ]".

Now that I look at it I can agree that it lacks readability if you're not used to it. I don't like XML and it's cumbersome to use but maybe this could be better.

I'm with JamesD, XML can be worst sometimes. Sections here and there...

No, no need to go to XML. Once understood it's enough to understand and customize it. And if it is true all I read about, that json is faster, go for json.

I only request to all skins developers to keep the tree structure for readibility purposes, even if it is not needed. Don't do the same as almost all of you do with macros and javascript scripts that write everything in one line, because it will become harder to find icons definitions.

Quote
Dorian

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

No, it's the icon size. Since the icons are shared, all buttons must have the same dimensions.

I see now. Thanks. As icon size is defined in icons.cfg, any toolbar created calling an action defined should respect the size defined on it.

I see now what you were asking opinions for Now the toolbars haven't different sizes defined as:

#  ToolBar Name(16,16) {       # (width, height) is optional, defaults to 16, 16
#     Button Name(16, 16) {    # (width, height) is optional, defaults to toolbar dimensions

All depends on icons.cfg.

And if we follow the thread subject this will only apply for toolbars, right?, not affecting menu icons.

Quote
JamesD
I would just like to have verification that the image order in each column is Hot|Cold|Dead.

Sorry, cold is first

Quote
siria
And in general: would there only be disadvantages or also any advantage over the current skin system?

Having toolbars.cfg reunited with its friend menus and accels, dpi support, more consistency.



Edited 1 time(s). Last edit at 11/09/2014 08:34PM by Dorian.

Quote
Dorian

Quote

JamesD
I would just like to have verification that the image order in each column is Hot|Cold|Dead.

Sorry, cold is first smiling smiley

OK, not a problem. Now I can fix my personal images and be ready to include them.

Well he have more than 100 old skins. Will they be usable still?

Quote
guenter
Well he have more than 100 old skins. Will they be usable still?

All would require updates. I was going to try to make some compliant with KM 74, but now must wait to have a working KM with new methods before I can start.

The question is "Can I change the skins?" What about the authors' permissions? Are some skins or images copyrighted?

@Günter

One has to decide what's more important, 100 old skins or an evolving browser.
It's just my opinion so don't beat me for it.

Same applies to extensions. I assume that some of them don't work out of the box already.

@JamesD

Maybe some of the skiners will update their skins.
As for reversing a magic pink .bmp into a transparent .png, it could become a cumbersome task for some images.
Fortunately it's easy to do so with the Klassic skin.

Quote
Yogi
As for reversing a magic pink .bmp into a transparent .png, it could become a cumbersome task for some images.

Suddenly, I get the feeling that there is something I should know, but I don't.

Does magic pink work in a PNG or do I need to convert that to alpha channel?

Quote
JamesD

Quote
Yogi
As for reversing a magic pink .bmp into a transparent .png, it could become a cumbersome task for some images.

Suddenly, I get the feeling that there is something I should know, but I don't.

Does magic pink work in a PNG or do I need to convert that to alpha channel?

AFAIK, the magenta gives transparency ONLY to BMP files. I guess this started because the lack of knowledge/support of BMPs with alpha channel.

PNG files, in the other hand, have alpha channels from the beginning and it is well known. This feature comes as it was intended for a replacement of GIF (to replace kind of a similar feature as BMPs+magenta, but with any color, but not actually alpha channel) and partially JPEG as internet image format (more quality for not complex images, as the compression suffers along complexity).

@Yogi, I don't think it would be a big problem.

BMP skins are actually pixel art, and haven't complexity in backgrounds/magenta. I mean, there aren't shaded colors, as are with alpha, to make half transparencies.

The task in the end is to replace/make magenta transparent and convert to BMPs+alpha to PNG, which shouldn't be a deal.



Edited 1 time(s). Last edit at 11/12/2014 01:04AM by JohnHell.

Nothing complicated about converting a plain magic-pink pic into a png with just 1 transparent color:
Open old bmp with IrfanView (or any normal image editor), then SaveAs / PNG, check option transparent, save, click into background.
All pixels with the same color (be it magenta or any other) get fully transparent.

More complicated than transparency is to stick the hot/cold/dead version together, although not such a big feat either: Open Irfan, click menu image / create panorama image / choose single origin pics, arrange order, save as png.

But ONLY good old magic pink images are so easy, because they only contain 1 color that shall be turned transparent, and to full 100% transparency.

Far more complicated to manipulate will be the modern skin images like Aura or the ones by jsnj, or finished new skin pics, with multiple transparency-opacity shade colors. THAT needs a much more advanced image tool.
And for me that x*y pattern additionally means no visible grid possible anymore at the bottom line, that could be used to paint with a pencil with plain simple tools like MS Paint or IrfanView.

Actually that magic-pink system is so easy because the images themselves are not transparent at all. Magenta is just one opaque color like all others. It is K-Meleon which has some programming somewhere that all magenta pixels shall be displayed transparent, and that probably could have been decided for any other color too. But it makes sense to have chosen one that usually appears as little as possible inside the icons themselves, because ALL pixels with that color will be shown transparent.



Edited 2 time(s). Last edit at 11/12/2014 01:14AM by siria.

Quote
JohnHell
BMP skins are actually pixel art.

If that's always the case then it indeed isn't a deal. The Klassic skin, the only one I looked at, is such an example.

Quote
JohnHell
and haven't complexity in backgrounds/magenta.

I had such images in mind.
You can easily transfom a complex transparent PNG with shaded colors into a magic pink BMP, that will look perfect.
Copy & paste such a complex transparent PNG into an empty image filled with magic pink/ff00ff, save as PNG and then manipulate the header of that PNG by saving it as BMP. Reversing back that BMP into a complex transparent PNG might be cumbersome.

Quote
siria
Far more complicated to manipulate will be the modern skin images with multiple transparency-opacity shade colors.

I had such kind of images in mind.

Quote
siria
THAT needs a much more advanced image tool.

Good luck with that, even with GIMP, the most advanced freeware tool I know.
You might end up editing pixel by pixel.

Quote
JamesD

Quote
guenter
Well he have more than 100 old skins. Will they be usable still?

All would require updates. I was going to try to make some compliant with KM 74, but now must wait to have a working KM with new methods before I can start.

The question is "Can I change the skins?" What about the authors' permissions? Are some skins or images copyrighted?

JamesD - that is hell of a work. I bit that bullet once in 2007. I reordered the toolbars so that they have the same order which prevents that all in in disaray after a change of skin...

IMHO all are free to update the code. That is what we would be doing. They are joined to free codes that this project owns so we a free to change that part.

The icon sets mostly come from other free browser projects or came like Klassic (IE / MFC embed icons) with VC versions that the K-Meleon devs owned.

@ Yogy. The codes are AFAIK in a kpluging. You could either keep the old plugin functional/usable or keep the codes in the new plugin and make a switch.

Or break the bridges back.

As for changing a BMP with Magic Pink -> modern Format. That can probably be done with Irfan View as a batch job where You choose Majic Pink as transparent color.
Maybe change to gif first and then to another format. Later You can change the extention in the toolbars.cfgs for the whole lot of skins with editors that can edit multiple files at the same time .bmp -> .png or whatever. Much like a batch job too. That is if some backward compatibility remains.

The problem is that the bmp.bars with the icons have 2 or 3 different chiefly used orders. It depends where they originally came from. They AFAIK mainbly come from Firefox, Maxton and NeoPlanet the first fully skinable browser. Or use their icon order as example.

So we need a way to pass on to the new system on the info - which icon in the picture.bar to use. The old plugin can do it.

And/or a way to convert almost 150 different skins cfg as batch job.
Else write a how to and let the useres of the respective skins do the job.
If only the default order is possible they must edit the picture to follow the new order.



Edited 1 time(s). Last edit at 11/12/2014 10:33AM by guenter.

@ Yogi and guenter

I have a bunch of software for images. Upaint, Xnview, Infranview, and Color Quantizer, I just cannot seem to find instructions on creating the alpha channel. I think all of the software might show the alpha channel, but I don't have any idea of how to change magenta or any other color to alpha.

Guenter, you noted that I might have to change from bmp to gif first. Will I be offered more options if I do that?

What about making a canvas with just alpha channel and putting the bmp with magenta over it? I am just grasping at straws here.

Try with Gimp, it also exists for Windows.

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

@JamesD, I already was going to recommend yesterday, as Siria's said, IrfanView.

The batch convert to PNG selecting a transparent color for every image is a child's game.

I just did now with the Aura that comes with K-meleon 74 that has both BMPs, with magenta and alpha.

No pain at all to do. Not need to convert to GIF or other deep tasks.

Here are the results:


hosting imagenes














sube imagenes




But let me ask a question. The example "is clear" but are we sure they are going to be PNG? Dorian hasn't said anything, right?


About the order... who cares the order? The new icons.cfg define the commands that associate images, then..., no need to be in order :-?



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

@ JamesD

For pixel art BMPs like those of the Klassic skin that don't have complexity in backgrounds/magenta, the easiest way is to use Greenfish Editor Pro.



Save as PNG.

That's it.

Edit: Sorry
GFIE Pro may not work on Win98!
It might not work on W2K too. At the time I was on W2K I have used an older version.
That worked (3.30???).



Edited 4 time(s). Last edit at 11/12/2014 04:31PM by Yogi.

So if I make the background magenta, I don't need alpha channel? I save in png format.

Ok, I read more and see what to use in Infranview.



Edited 1 time(s). Last edit at 11/12/2014 04:23PM by JamesD.

Mmmmm, is it me or BMPs+magenta become greenish with IrfanView convert? :-?

Might be that greys are converted to alpha too... Curious.



Edited 1 time(s). Last edit at 11/12/2014 04:33PM by JohnHell.

@ JohnHell

Hmmm, you can simply open the Aura skin transparent bitmaps in XnView and save them as PNG.
For those with magic pink you can use GFIE Pro.



Edited 2 time(s). Last edit at 11/12/2014 04:48PM by Yogi.

Quote
JohnHell
@JamesD, I already was going to recommend yesterday, as Siria's said, IrfanView.

The batch convert to PNG selecting a transparent color for every image is a child's game.

I just did now with the Aura that comes with K-meleon 74 that has both BMPs, with magenta and alpha.

No pain at all to do. Not need to convert to GIF or other deep tasks.


But let me ask a question. The example "is clear" but are we sure they are going to be PNG? Dorian hasn't said anything, right?


About the order... who cares the order? The new icons.cfg define the commands that associate images, then..., no need to be in order :-?

Guess I should update to a newer Irfan Viewer.

Currently we are at bmp with alpha channel support.

And Dorian's example is definitely a png. So that is the way.

And IMHO that is definitely an improvement. Better quality possible.
& we will be able to use Firefox skins' png. :drool:




The command does IMHO not associate the image but the position of an image inside the png with a command. Now that does not matter for the first couple of images. The are all the same.

But in the long old pics they may differ at the end when they have another origin.



Here already after image 4 or 5. If compared to a Firefox icon bar.



Edited 1 time(s). Last edit at 11/12/2014 06:55PM by guenter.

I may or may not have done this correctly. I changed one image in NewPhoenity skin.

Before: 25 KB


After: 3 KB w/compression at 8


I don't know if the new image is correct or not.

Now that I have seen the preview here, I doubt that it is correct. PNG does save a lot of space.

Quote
guenter
Guess I should update to a newer Irfan Viewer.

LOL! Looks like we had the same sudden brilliant idea when looking at Johns screenshot
And to my amazement the current version can even show a fixed grid!
The only drawback is it seems to have a little bug, that grid isn't quite so "fix", when scrolling it looses 1px at the sides.

2.55 KB compression level 6 with GIMP

But, did you add the magenta, because it isn't transparent.

And, also, this image is a little tricky as it has 2 or more colors to make transparent. Look at this zoomed image. There are various greys to remove:




This should be the result (zoom it to see the difference):


(note: I used magic wand and photoshop, but could be make in irfanvew in serveral steps (as PNG is lossless) until you pic every color needed to make the background transparent)

EDIT: damn it don't post while I do LOL

@yogi mine is 2412 bytes 2.35KB

@JamesD, about the order, every skinner should have the choice to choose it. There is no need of standardize.



Edited 3 time(s). Last edit at 11/12/2014 09:15PM by JohnHell.

LOL! It doesn't really save that much.
Converted James' original 25-kB bmp manually into a 16-color bmp with irfanview, and now it's just 3.2-kB bmp
Seriously, in times when no one seems to care a thing about loading web pages with megabytes of scripts and css files, 1kB really is nothing. Not even on my ancient machine.



Edited 1 time(s). Last edit at 11/12/2014 10:47PM by siria.