(Very Small) requests... :)

Hello,

  1. When I select an icon in the selector, I’m always redirected to a blank page. I’d like to return to its category, with the icon highlighted directly (this also applies to custom icons). It would also be helpful to have a “Preferences” icon category and/or an automatic category grouping all icons used in a grid. Additionally, icon identification (for example, with a reference number underneath) would be a plus.

  2. We should be able to edit multiple buttons/elements simultaneously, either relative or absolute.

  3. Adding a background image isn’t ideal. Please provide an option to do this directly in a grid editor, so we can see the result more easily and add our own background images.

Otherwise, your application is fantastic! Well done!

Thanks again!

Thierry :wink:

Thanks Thierry — really appreciate the encouragement. Here’s a breakdown of the points you raised:

1. Icon selector opening on a blank page

This is intentional. Iterating through a large icon collection every time would slow the selector down noticeably — we tried it, and the experience was poor. Starting with a blank view keeps it fast.

If you want to jump directly to the currently selected icon, just tap the arrow in the top bar of the selector — it takes you straight there.

2. Editing multiple objects at once

We get where you’re coming from. Right now, the “Paste Style” option covers most of these multi-edit scenarios. It’s not perfect, but it avoids a much bigger UI problem: introducing multi-selection directly in edit mode breaks the core flow.

Currently, a tap = selecting a single object. If we switched to multi-selection, tapping would constantly add/remove items, which makes basic editing frustrating. We previously had a multi-select toggle in the top bar — it created more confusion than value. The current model is far more predictable and reduces accidental selections.

That said, we’re still exploring ways to bring more flexible multi-editing without compromising the simplicity of the editor.

3. Custom background images

This is on our roadmap. The main constraint is file size — adding arbitrary images to grids would make imports/exports significantly larger. Right now, grids only store references to predefined assets, which keeps transfer sizes tiny.

As for not showing the background in edit mode — also intentional. Displaying it there reduces the visibility of the base grid and makes precise layout work harder.

We’ll revisit this as we rethink our grid system; custom backgrounds are definitely something we want to support.

Thanks again for taking the time to share this — really valuable input. Keep it coming!