I have to add that I have often received great help in this forum from folks like @s-molinari or @metalsadman and others. It is often difficult to get into the deep details of a particular problem, given the broad range of functionality offered by Quasar and Vue. I’m really impressed how you folks often come up with the right answers or at least pointers to the right solutions. Keep going!

All the best for Ravzan, get well soon. Your work is incredible, in terms of innovation, quality, and quantity.

As a first step, I tried a flex box as suggested by @metalsadman to align the q-toggles. Here is a code snippet that shows the concept, using class=“col-2” for each q-toggle, which means 2/12 of the available space in the row:

<div v-if="$q.screen.gt.xs" class="row full-width">
        <div class="col-2">
                <q-toggle
                      v-model="visibleColumnsMaterialEigenschaften"
                      val="schallSchutz"
                      label="Schallschutz"
                 />
        </div>

It took me a few attempts to find out that it needs class=“full-width” to work properly.

The result has up to 6 toggles per row that are aligned nicely:

After realizing that Heroku as the deployment environment for my Quasar app has restrictions with uploading/downloading of files, I’m now looking for some sample code how to use q-uploader to upload files to Amazon S3..

I’m not familiar with S3 yet and have used q-uploader so far only in a simple way, to upload files to the file system of the Quasar frontend app.

All I found so far as a boilerplate to start from is a tiny code snippet on the old Quasar site (https://forum.quasar-framework.org/topic/5382/how-to-use-q-uploader-in-quasar-app-deployed-on-heroku ) that uses q-uploader with so called signed S3 URLs.. It uses a q-uploader prop :url-factory=“getSignedUrl”, but I can’t find that prop in the API documentation of the current version of q-uploader on https://quasar.dev/vue-components/uploader#QUploader-API.

Is there another sample or Codepen how to use q-uploader to upload a file to Amazon S3?

Would greatly appreciate some advise.

Wow…so I tried this combination of v-model=“toggleAllNormkategorienState” and @input=“toggleNormkategorien”…which is in my view a bit “creative”…at least not what I would have expected from the docs

On the first try, I got disappointed because it did not immediately work for me (neither control for table column visibility nor the ticking of q-toggle, worse than my original combination of @input= and value=).

But the additional trick to get this combination to work was to REMOVE the inverting of the toggleAllNormkategorienState from the toggleAllNormkategorien method. So, with that super-creative combination, it seems to WORK!!! Still need to a bit more testing to be 100% sure.

Thanks a lot for your always competent and quick help.

I compared your code again with mine, and have been able to find the cause why my q-table did not show up as “dense”. It was kind of a user error: I had put “dense” attributes on all checkboxes in my q-table, but not on the first Quasar related checkbox, which does the selection of a row in the table:

<q-td :auto-width="true">
        <q-checkbox v-model="props.selected" dense />
 </q-td>

With that “dense” property on the row selection checkbox and “dense” properties on all other checkboxes, my table is now “dense” as well:

@metalsadman - thanks a lot, I would not have caught the root cause without your Codepen!

I figured it out, but as part of testing, realize that I would prefer such a context menu to select a new node in the tree on the header slot, not the body slot of my q-tree.

In the body slot of my q-tree,

<q-menu touch position context-menu>
  <q-list dense>
    <q-item clickable @click="selectedKeyMyTree = prop.node._id">
      <q-item-section>Select node</q-item-section>
     </q-item>
  </q-list>
</q-menu>

does the above job to change node selection to the node under the context menu.

Is it possible to have such a context menu on the header slot that is able to change the selected node (and also offer some other actions)?

I did one more experiment, and got a context menu also working on the header-slot. Strangely, in the header slot I had to change the code that assigns the new node in the context menu to

<q-item  clickable @click="selectedKeyTreeBaustoffe = node._id">

The code I used in the body slot, if used in the header slot, results in an error that prop and node are undefined:

<q-item  clickable @click="selectedKeyTreeBaustoffe = prop.node._id">

Not sure why this works differently, the API doc looks the same for header and body.

Anyway, my last question is: How can I change the selected node in the context menu and subsequently trigger some other method when the user right clicks the context menu?

@FrankM - agree completely. Web sockets (compared to push notfications/service workers):

• are more powerful, given the richness of the socket.io API (except this “notify disconnected users” which is not important to me)

• are easier to set up

• can be used with http for dev environments

• can be easily integrated with Quasar. I now put the web socket setup into a Quasar boot file, so I have them available in all components through $socket.

• are not dependent on experimental browser functions (push notifications still are classified “experimental”, afaik)

Thanks for your advise.

@FrankM - agree completely. Web sockets (compared to push notfications/service workers):

• are more powerful, given the richness of the socket.io API (except this “notify disconnected users” which is not important to me)

• are easier to set up

• can be used with http for dev environments

• can be easily integrated with Quasar. I now put the web socket setup into a Quasar boot file, so I have them available in all components through $socket.

• are not dependent on experimental browser functions (push notifications still are classified “experimental”, afaik)

Thanks for your advise.

@dobbel - thanks, good hint. It looks like I hadn’t seen the forest (frontend solution) for the trees (socket APIs at the backend).

@dobbel, @FrankM - I have now prototyped web sockets. Using socket.io on backend and frontend. The code is much simpler than the code for push notifications. And web sockets are easier to integrate with Quasar, because you can listen and handle socket events triggered by the backend in the frontend main component code (my-layout.vue) and directly react to such a socket event e.g. through a Quasar QNotify notification with a refresh action.

The only little caveat I have with these web sockets is this: It looks like it is not straightforward to exclude the client that created the new content from a “new content” notification. There is a so called “broadcast” feature in socket.io which excludes the “initiator”, but, unless I misunderstand the concept, the “initiator” is always the backend server, and it is up to the programmer to relate it to a user on a client, and exclude that client from the notfication. Not sure yet how to do that with web sockets.

@dobbel - thanks, Workbox is one of those powerful PWA specific features that aren’t available yet to me because I’m still reluctant to make the move from SPA to PWA

@dobbel, yes, I see an app.use for a service worker in the code at https://github.com/smolinari/quasar-docs/blob/master/src-ssr/index.js, but couldn’t find the service-worker.js itself yet.

@dobbel - yes, I had overlooked initially that these push notifications are from server to individual clients. If you want them for all clients, it is on you to to loop through all subscriptions and send push messages to every single client.

I think @FrankM 's solution is the most powerful one, but probably even more complicated than my prototype for push notifications (which needs web-push package on the server).

I hope web sockets can do what I need.

@metalsadman - do you happen to know how Quasar has implemented the notifications that new content is available on the Quasar docs site?

@FrankM, @dobbel - I have been prototpying push notifications for my existing SPA app.

It has been a bit tedious to set everything up, but I got it working. It consists of 3 pieces:

• Registering a service worker and subscribing to push notifications - currently this resides in the created() part of my Quasar main layout (my-layout.vue)
• Service worker - I placed this temporarily in the /statics folder of my frontend code. This piece of code receives the push notifcations and does showNotification()
• Backend code: This piece of code is still experimental, it fires a push notification using the NPM web-push package

I got the overall mechanics working.

I’m a bit disappointed to learn that it is only for a single user. In order to notify all or selected groups of users, the subscription details would have to be stored for every user in my backend database. In order to notify all users, I would have to iterate through these details and create a push notification for every user.

This web push mechanism is pretty complicated for what it delivers.

I will probably experiment next with web sockets,

@FrankM, @dobbel - can you take a quick look at my last append? I’m still struggling a bit with the basics of web push notications, unsure where the client code pieces belong in a Quasar app (still SPA at this point).

Wow, I’m impressed by @FrankM’'s “layered” notification approach. Gives me a lot of food for thought.

My app is less “collaborative” though, so I’ll implement at least initially a simpler mechanism.

Currently I’m looking at this tutorial: https://thecodebarbarian.com/sending-web-push-notifications-from-node-js.html

I’ll probably try to put the server part of that code into my backend server.

I’m not sure yet about the client part of that code. Maybe I can integrate that into my static Express web server for Quasar? Or does it belong into the Quasar my-layout.vue main code (mounted or created part)? The other tutorial @dobbel pointed to, says it is normally put into the index.js file of the frontend code…you see that my understanding of it is still too limited.

[Update: In my prototype mentioned further below, I put the client part (registration & subscription) into created() of my-layout.vue]

Then I still have to figure out where to place and find the service worker code itself (which is in a separate worker.js file in the tutorial) within my Quasar frontend code structure.

@FrankM, @dobbel - thanks for sharing your adivse.

The potential conversion from SPA to PWA, though @dobbel said it isn’t that hard, sounds like a big overall change to my app. Probably not justified if only for the sake of this small enhancement.

But honestly I don’t undestand the impacts and pros and cons of PWA vs. SPA.

I’m a bit scared that I have to do a lot of regression testing and potential changes to my build and deployment process (locally and on Heroku Cloud) for PWA.