Possibly weirdly, I can't really spot the difference between them. 😉

That being said, I've no objection to this at all. Is it ready for merging?

Ahhh, there's a reference to the old filename in snapcraft.yml:

$ grep -ri "sqlitebrowser.svg" *
...
snap/snapcraft.yaml:          icon:                   images/sqlitebrowser.svg

That'll likely need updating too. 😄

Possibly weirdly, I can't really spot the difference between them. wink

Same. When they are put like this next to each other it is hard to tell. But I found a way! 😃

Open both (before and after) on different tabs next to each other and quickly switch between them to see the difference. 😄

Or make a GIF. Here is an example (from the first change only) ...

Here's the full change...

@revolter Nice job. The logo looks better now. 👍

Ahhh. Good thinking. That makes it obvious. 😄

Agreed, good stuff. Definite improvement!

That'll likely need updating too. 😄

I'll fix it tonight

That top outline bugged me for so long :))

Fixed. Please let me know if there are other images that need to be exported from the new SVG, and I will do so.

Good thinking. Doing a quick look through the repo for other likely exports of the same icon file shows up these:

General

• https://github.com/sqlitebrowser/sqlitebrowser/blob/master/src/icons/sqlitebrowser.png
• https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/resources/icon.png

Windows installer pieces

• https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/background.bmp
  • Likely generated from: https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/resources/background.xcf
• https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/banner.bmp
  • Likely generated from: https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/resources/banner.xcf

macOS installer pieces

• https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/macos/macapp.icns

Not sure about the macOS icon file, but the others should be fairly simple to regenerate. 😄

Not sure about the macOS icon file, but the others should be fairly simple to regenerate. smile

iconsets:
https://blog.macsales.com/28492-create-your-own-custom-icons-in-10-7-5-or-later/
can be done in cmake or scripting

CMake I've done elsewhere to automate...

    SET( SRC_PNG "logo_1024px.png")
    SET( SRC_PNG_PATH "${CMAKE_SOURCE_DIR}/images/${SRC_PNG}")
    SET( DEST_ICS "${CMAKE_SOURCE_DIR}/images/${PROJECT_NAME}.iconset")
    ADD_CUSTOM_COMMAND( TARGET ${PROJECT_NAME} PRE_BUILD
        COMMAND mkdir "${DEST_ICS}"
        COMMAND sips -z   16   16 "${SRC_PNG_PATH}" --out "${DEST_ICS}/icon_16x16.png"
        COMMAND sips -z   32   32 "${SRC_PNG_PATH}" --out "${DEST_ICS}/[email protected]"
        COMMAND sips -z   32   32 "${SRC_PNG_PATH}" --out "${DEST_ICS}/icon_32x32.png"
        COMMAND sips -z   64   64 "${SRC_PNG_PATH}" --out "${DEST_ICS}/[email protected]"
        COMMAND sips -z  128  128 "${SRC_PNG_PATH}" --out "${DEST_ICS}/icon_128x128.png"
        COMMAND sips -z  256  256 "${SRC_PNG_PATH}" --out "${DEST_ICS}/[email protected]"
        COMMAND sips -z  256  256 "${SRC_PNG_PATH}" --out "${DEST_ICS}/icon_256x256.png"
        COMMAND sips -z  512  512 "${SRC_PNG_PATH}" --out "${DEST_ICS}/[email protected]"
        COMMAND sips -z  512  512 "${SRC_PNG_PATH}" --out "${DEST_ICS}/icon_512x512.png"
        COMMAND sips -z 1024 1024 "${SRC_PNG_PATH}" --out "${DEST_ICS}/[email protected]"
        COMMAND iconutil -c icns "${DEST_ICS}"
        COMMAND rm -R "${DEST_ICS}"
    )

Cool. 😄

Not sure how that icon was first generated. Knowing me, it was probably using some output format of either Inkscape or Gimp. But no guarantees. 😄

It's not really well publicized "how to" make a mac icon. Process has similarities to Windows icon file creation. Secret sauce to success for both is to start with a large pixel count, high-res image and scale down accordingly. If you noticed in the code posted above, sips does the heavy lifting to scale down an image on macos (in lieu of imagemagick/GraphicsMagick/gimp et al). iconutil slaps all the images together into a single file.

Looking at the gifs, it's a bit jarring to see the movement. Any chance you can keep the cylinders in place and make the shading fade in/out?
The images at the top look good.

start with a large pixel count, high-res image and scale down accordingly

Or with a SVG file.

Looking at the gifs, it's a bit jarring to see the movement. Any chance you can keep the cylinders in place and make the shading fade in/out?

I don't understand this. The GIF was made for reference only. You can download the versions of the logo.png image from the commits and compare them the way you like.

Looking at the gifs, it's a bit jarring to see the movement.

I think the movement is on purpose, with the main cylinder piece being "incorrect" by a small amount in the original. eg it's being moved into the correct place

start with a large pixel count, high-res image and scale down accordingly

Or with a SVG file.

IIRC, sips doesn't work with svg's. Nor does windows ico( I think?). Sure. Create the large pixel count, high-res image as an svg but ultimately the svg would have to be exported to a png/jpg for image container generation.

with the main cylinder piece being "incorrect" by a small amount in the original. eg it's being moved into the correct place

Actually, it looks like it was centered correctly before. I will look into this.

The gif observation is just that. An observation. Having "disc cylinders" moving laterally (virtual or physical) was always a bad thing in my experience. 😉

IIRC, sips doesn't work with svg's.

Then we should use ImageMagick instead of sips, if we want to automate it.

IIRC, sips doesn't work with svg's.

Then we should use ImageMagick instead of sips, if we want to automate it.

Imagemagick adds a dependency whereas sips/iconutils is apart of mac os system.

Imagemagick adds a dependency whereas sips/iconutils is apart of mac os system.

But exporting different sized images from a bitmap is lossy, whereas exporting them from a SVG is lossless.

I think the "only svg" stance is a bit overzealous. Besides, sips/gimp/imagemagick et al do a good job of scaling down the svg image to size before exporting. Honestly, does it really matter if the 16px^2 image is highly accurate rendition of the original?

My last point on the subject...
Icon sets on Linux do both svg and png/jpg (multiple sizes). If you have a look in /usr/share/icons, you'll see a scalable folder (with svg images) and various (px size)x(px size) folders (with png/jpg images). They're all in there. What gets published is a matter of end usage. Some desktops, IIRC, require menu images be png/jpg (or even xpm) format. Cover bases as best possible.

If you have a look at https://commons.wikimedia.org/wiki/Comparison_of_icon_sets you can see the various flavours and styles being employed. Personally, I think Tango over-works the effort with shadings et al. Icons should not be a 48px re-interpretation of the Mona Lisa. Convey what it does and move on. My $0.02.

...addendum to my last (opps)
The need to regenerate the icon file should only be necessary IFF the source image has changed. Yes, absolutely, document how the heck you created the icon file in the first place to head-off long threads full of ideology and philosophy (from the likes of myself 😉). Then if the image changes future-devs have code/scripts to work with to update and can deal with dependencies/availability at the time. Generating the icon file each and every time the sources get compiled, IMHO, seems impractical.

https://github.com/sqlitebrowser/sqlitebrowser/blob/master/installer/windows/resources/icon.png

@justinclift, Do you have any idea why is this icon darker than the default one?

Awesome. 😄

@justinclift, I think this is done, except the OS/2 icon. Let me know it everything is ok. I also documented all the changes and steps that I did in the PR's description, for future references.

@TeLLie, You could add the OS/2 icon directly to this PR, or you could send it here and I'll commit it.

Sorry, here it is: https://github.com/sqlitebrowser/sqlitebrowser/blob/7c69b0e6df8a0c4c20bd1126ffd214a688aa79bd/src/iconwin.ico

Thanks heaps @revolter, merged. 😄

@TeLLie When you have the OS/2 version of the .ico ready, lets us know so that can be added too. 😄

Oh, I'm not seeing it. Hmmm, would you be ok to email it to me and I'll make sure it gets in the system? 😄

Fine...let's discuss it here...

The svg image (logo.svg) is an oddball size in the repo (39px^2).

It doesn't matter.

The png image (logo.png) is an entirely different story. 866px by 938px. Really?

That's because I exported the Drawing, and not the entire Page, in case someone wants to manually add a custom padding to the PNG, or use it without padding at all.

Ideally for distributions, svg/png images should be framed as square and have a size of 16, 22, 24, 32, 48, 128, 256, or 512 px.

The size of the SVG doesn't matter. If you use it in HTML, it will have the size specified using HTML attributes or CSS, regardless the size shown in Inkscape.

I think this needs to be tweaked a little.

Would you be up for a separate PR?

From your commentary I can infer that you are not familiar with software distribution. There are standards and best practices involved. The it doesn't matter in HTML philosophy doesn't fly with package maintainers. Last thing we want to do is incur their wrath. Also, not having a consistent sizing in line with expected practices reflects poorly on the project, IMO.

This is your PR - I would encourage a re-think and better awareness of how downstream distributions expect stuff. Let's not make unnecessary work for others.

From your commentary I can infer that you are not familiar with software distribution.

Indeed.

There are standards and best practices involved. The it doesn't matter in HTML philosophy doesn't fly with package maintainers. Last thing we want to do is incur their wrath.

We are not distributing SVG files, we are distributing PNG files.

This is your PR

But I did not change anything related to the size or document properties! The SVG file is like that since 2014.

Let's not make unnecessary work for others.

I only changed the x and y position of some anchor points, nothing more.

I guess the question here is "what do we need to do, in order to make the logo/images stuff easier for distributions?"

Without going fully overboard and taking 3 full man years of effort kind of thing. 😄

I guess the question here is "what do we need to do, in order to make the logo/images stuff easier for distributions?"

Wasn't the distribution easy before I moved a bit some anchor points?

Definitely. I'm just asking as a generic thing as @scottfurry sounds more knowledgeable than either of us in this area.

I don't think there was anything wrong with your PR, but that doesn't mean we can't make things better for downstream packagers in a follow up one at some point. 😄

but that doesn't mean we can't make thing better for downstream packagers in a follow up one at some point.

Of course, but in a separate PR, which would have nothing to do with the changes I made.

Good point. 😄

I understand the submission was being done to address a problem you found. Great!
However,... there are other considerations that get brought out because of the change. I realize now that I had manually created a local icon cache in my home directory to circumvent the oversized svg that ended up in my menu. But while we're here...

For Gnome (predominant Linux unfortunately): https://developer.gnome.org/hig/stable/icon-design.html.en
Mac: https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-icon/
Windows: https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-icons

tl;dr version - keep icons square. stick to conventional sizes. don't bury stuff that someone else has to dig for to retrieve.

Having a similar (or unrelated) image buried in the [project root]/src/icons folder seems bad. Is there a reason it's there? Clean up? Does the image at this location need to be updated with update to the source svg?

From a packaging perspective, the [project root]/image folder will be looked at as the "canonical source" for where to grab icons. So a high-res svg image here would seem ideal (512/256px - dealer's choice but certainly not 39px^2). The png in the same folder should be of expected dimensions. 48px^2 is good for menu entries. If we get a request for a different size than implementation is straight forward (scale and export svg to an additional size - done).

Take away here is consistency.

tl;dr version - keep icons square.

I did keep them square. More exactly, I exported ALL of the rasterized images to the sizes that they had before this PR.

Having a similar (or unrelated) image buried in the [project root]/src/icons folder seems bad.

I don't know what you're talking about. The only image that I added is [project root]/images/logo.png.

So a high-res svg image

A SVG file is a vector, not an image. Hence, the resolution is completely irrelevant.

The png in the same folder should be of expected dimensions

So the issue is that I added that [project root]/images/logo.png?

If so:

1. I added it as a "dump" of the SVG file, so anyone can actually see the changes between the commits:

vs

2. Why didn't you say this from the beginning? We can delete or move it then.

If not, then, what is the actual issue caused by this PR?

@revolter Pretty sure there's no actual issue caused by this PR, and @scottfurry is just trying to suggest improvements, but in a clumsy way. (sorry Scott) 😉

Lets move this conversation to a new issue, where we can discuss improving the current packaging images/logo, so things are easier for distributions?

There is changes to the tree that also impact packaging/usage. I don't agree with your observations and opinions about svg but that's just definitions. However, let's make changes the tree to consider packaging expectations.
Things needed, IMO:
a) an svg file w/ square image of pixel size mentioned earlier;
b) a png/jpg image derived from that svg and is usable as a menu entry (at least 48px, by 24px also would be useful); and
c) make sure we are not leaving any residual logo files in the tree (i.e. the one I mentioned in src/icons/.