This month’s round-up focuses on improving productivity, collaboration, and convenience when using Baserow. Say hello to:
→ Email notifications
→ Workspace-level audit log
→ Search for the Calendar view
→ New shortcuts
→ Context menu improvements
Get the full list of all Baserow updates.
Baserow updated successfully. 
Much nicer design and font. But color palette is somehow changed - all colors are a bit less saturated and maybe hue is not as balanced, so at some color tones it’s difficult to recognize the difference. Please, can finetune it (or biring back the older one)?
What is bad: the whole thing is so much slower now - filtering, search, switching between views etc. Don’t know why. 
Sometimes I hae to wait minute or more, this is really very annoying… Is there any parameter in configuration which was changed comparing to a previous version??
EDIT: shortcuts Shift+cursor left/right and Shift+cursor up/down - nice functionality and I have to say, that selecting multiple rows or columns by this way is much faster than by dragging with the mouse.
But I also have to say, that I already have got cheated by this system as I used to use these shortcuts for selecting a part of text inside the text type fields. As usual in system and text editors, the Shift+cursor left-right is commonly used to select part of the text, also CTRL+Shift+cursor left/right is for quick selecting of whole words. Now when I use this shortcut, my text selection is canceled immediately and whole row fields are being selected.
My suggestion: could you add the “turn on/off” checkbox or switch for this new feature somewhere in the UI? Because I believe these new shortcuts can be very useful sometimes, but in other time I would rather turn it off temporarily.
Hey @marcus, glad to hear that Baserow updated successfully for you.
We’re going to roll out design changes with every release in the upcoming months. In the last release we indeed changed our color palette, but the saturation difference between the variants should almost be identical. I agree that the hue difference between yellow and orange is not enough here. We’ll look into that. Are there are any colors where you find the hue difference not enough?
It’s a strange that the performance is much slower for you, especially because we’re barely touched those systems in 1.20. We have been working on improved search and sorting performance in 1.19, but that should have one been faster. What was the old Baserow version you ran before?
Can you also share some more information about the number of tables, total number of rows per table, and which server specifications you have for your Baserow instance?
The Shift+Arrow keys enabling multiple select while editing a cell value seems like a bug, this shouldn’t happen. We’ll fix it asap.
I run baserow as selfhosted on my Synology NAS (DS1618+) - specs are I believe OK as it is Atom C3538 4-core with 32 GB RAM and I also have 2x 500GB NVMe SSD for read/write cache.
Previous baserow version I had was v 1.19.1, yesterday evening I updated to v1.20.
My database contains 7 tables, except of two of them they have just a few rows (between 5 to 20 rows each table), next table has 150 rows and largest table has 6200 rows (and 50 data fields/columns).
The difference in speed between v1.19.1 and 1.20 is really drastical - unfortunately the most recent version 1.20 is that one which is slower than previous version, as I said. Especially when using Search, filter, switchin between views or editing some fields properties, like trying to change colors in multiple-select items.
According to color palette - I’ll try to prepare some concept (fine-tuned palette) and will put it here today or tomorrow. If there would be some tool to tune the colors in baserow “live” then it would make the process much easier. Custom colors in baserow would be great too (let’s say that user would be able to get just any color from the system palette).
Hey @marcus, are there any resource limitations on the Baserow docker container itself? Would love to see some output logs of the backend after making doing a search query for example. It would also be great if you can share any configuration you have of Baserow on your nass.
Separately, the bug about the shift+arrow keys is fixed in this merge request: Respect can keydown method when multiple select via keyboard shortcut (!1661) · Merge requests · Baserow / baserow · GitLab.
Ok, I will try to dig out some logs tomorrow - would you give me some tips how to do it at best, where to find it etc? Can I use Portainer for it?
I will also provide to you my container configuration.
LIMITATIONS
I don’t think that it’s a problem of limitations. I limited my baserow container in Docker to 4 GB of RAM and CPU mid priority. I also tried to turn limitations completely off, but it didn’ help, so I turned it on back again - baserow container never reaches the limit (RAM in maximum oscillates somewhere around 2.5 GB, CPU is OK).
Today I tried to restart my NAS server completely, but baserow is still slow. I am wondering why, because version 1.19.1 was fast and with very quick response.
I might have been able to reproduce your problem on a 100k rows table of my own. We will be investing this on our side asap.
but still, my largest table has 6200 rows comparing to your 100+k … and is so slow.
I’ve identified the problem, and fixed it in this merge request: Fix view sort performance problem (!1662) · Merge requests · Baserow / baserow · GitLab. You can expect version 1.12.1 to be released tomorrow with a fix.
Thank you so much for reporting this!
I am sending you also the log (exported right after I did the serach), again via private message, OK?
Hi @marcus, I just wanted to let you know that we have already released version 1.20.1 (1.20.1 · Baserow / baserow · GitLab) with a fix for the performance problem. Thank you for all the information you’ve provided, it has been super helpful, and apologies for the inconvenience!
Great work! Thanks for quick update.
I redeployed and updated my baserow installation, now it works super fast again 
I also found one graphical glitch: longer row numbers (4- or more digit) are truncated - probably the result of newly used font (and not sufficient fixed column width - just guessing…):
Here is another graphical glitch - insufficient space (and missing scrollbar) for items from multiple select list during the filter creation. There should be more items visible when I started to type “rad…” (at least one more: radiologie - that one in light red color, see in table below the filter), but there is only one, and truncated:
Thanks @marcus! I wasn’t able to reproduce this problem on my Mac, but I agree that it’s probably related to the new font. I’ve given the row ID 2 pixels more width, which will most likely solve the problem for you. You can track this MR here: Fix row ID being truncated with 4 digits (!1665) · Merge requests · Baserow / baserow · GitLab
Which operating system + browser are you using? This will help me verify the fix this fix has been deployed to baserow.io.
Thanks for pointing that out! We’ve recently implemented some improvements in the scrollbars of the context menus if they don’t fit inside the viewport anymore. Apparently, we forgot to make some of the dropdowns compatible with that. I’ve created an issue for it here, but will make sure it’s going to be prioritized: Dropdowns in the filter context are cut off (#1965) · Issues · Baserow / baserow · GitLab
We’ve fixed this problem in this merge request here: Resolve "Dropdowns in the filter context are cut off" (!1668) · Merge requests · Baserow / baserow · GitLab. It will be included in the 1.20.2 release today.
Already released, or not yet?
