First round of review

[Krastanov]

Great job, guys! This looks already quite great! Let's do some final polish.

I structure my feedback as (1) main points with a reason for why it helps to make such changes followed by (2) specific examples of where the change would help.

[Krastanov]

First I discuss things that I saw on reading the src/CssMakieLayout.jl file

• Think of the docstrings as something that needs to answer "Why is this created? How to use it? What is it in terms of implementation?". The most important is the "Why" question, but frequently you first answer the "What" question instead. Let's fix that part of the documentation so it is easy for other people to use your library.
  • markdowned - it says it is optional, but the user would not know when to use makrdowned and when to use wrap. Answer that question. I see that markdowned is not publically exported, so it is not too important to document it (the users will not be exposed to it)
  • wrap - add a paragraph that would answer "Why would a user want to use / need to use this?"
  • hoverable is great
  • active can have a bit better documentation. Right now it reads as is you use it after you are done making the layout. Maybe phrase it as "When constructing a layout, this function marks an element as 'active', i.e. topmost in a zstack."
  • Another issue is that you use the word "active" to mean two different things. You use it for hoverable where it means "in the 'hovered' state" and you use it in active/zstack where it means top-most. I would suggest rewording the hoverable docstring.
  • zstack has a keyword argument observable which is quite confusingly named. There are many things that are observables, rather this is an observable used for something very specific. I would suggest renaming it to activeidx which is kinda the name you are already implying elsewhere in your code.
  • selectclass - that one really needs an answer to the "why", right now it is fairly inscrutable
  • modifier needs a "why" answer
• Avoid exporting things that the user will not be using. Being exported means it is part of the public API, that your users might start using it, and that it will be much more difficult for you to refactor it in the future.
  • selectclass should not be exported
• API quirks - these are things that do not seem very idiomatic for a Julia program, but are not big problems
  • hoverable has a keyword stayactiveif - that keyword should be a boolean one, not an integer one, and the default value for it should probably be Observable(false) instead of nothing
  • the observable keyword I mentioned above

[Krastanov]

Now onto the readme:

Intro is great!

• Warn the user what the most important tools are. E.g. add a paragraph that is a better version of something like "Here are the functions you care about: Most frequently you will be using the hstack, vstack, and zstack functions to create your HTML/CSS layout. You will be wrapping your figures in HTML div tags with wrap. When stacking things with zstack you will want to select which one is currently viewable with the function ... and the observable keyword argument .... Hover animations are available with ..., And for convenience you can create clickable buttons that navigate the layout with ..."

Example 1:

• avoid importing things you do not need; Base.Threads does not seem used for anything, and the TailwindDashboard is not used either.
• make a slightly more detailed comment explaining what activeidx is, again focusing on why the user needs it
• you do not use the :colorscheme key -- remove it so that the example is as minimal as possible.
• similarly, just completely remove proxy_url

Example 2:

• some of the comments from Example 1 apply here too, please go through them
• this one is important: you plot the figures twice, one for the main and one for the menu. Could you instead plot them only once and just put the same figure in both locations?

[Krastanov]

Logistics for registering the project:

• Could you move the project to the QuantumSavory github organization. I already added you as organization members so you should have access to modifying the repo, etc. The reason to put it in an organization is because repositories that belong to a user account can have releases created for them only by that one person. If it is in an org, whoever is available to fix a bug reported by a user can immediately make a release, without waiting for the organization owner.
• After you are done with all these tasks, I would suggest making a post on the julia discourse, briefly explaining what the library does and having one or two gifs. Happy to help you prepare a draft for the announcement. It would be valuable to ask for comments and suggestions from the community.

[adrianariton]

Regarding the last part about plotting the figures twice. At first i tried keeping the same figure in the menu and also in the main window, but they behave the same, meaning if i select some area on the main figure the same thing happens in the menu figures. Also because the figures in the menu are smaller, keeping the same figure and therefore the same resolution would make them look really weird because of the smaller area and larger resolution.