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!

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:

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

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?

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.

@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 recieves 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.

I once had a similar issue, which happens ONLY IF you have a q-btn with type=“submit” WITHIN a q-form. Try the following workaround:

1. Remove the type=“submit” from the q-btn
2. Add an @click=“someMethod()” to the q-btn to handle what needs to be done when the button is clicked

I have a Quasar based web app (SPA). I would like to notify users about new content available, preferably by a Quasar QNotify message coming up in the browser (for all logged in users). It appears that the Quasar docs web site itself offers that kind of a mechanism, but I’m not sure how it can be implemented for my SPA.

My Node backend code is the source of wisdom about new content. I see different possible mechanisms to achieve this - push notifications, service workers, browser notfications. I know these mechanisms are not Quasar functions, but I need to select the right mechanism and get it working together with my Quasar app.

In https://quasar.dev/quasar-cli/developing-pwa/handling-service-worker#Interacting-with-Service-Worker there is documentation how to interact from a Quasar app with a service worker, but it seems to be specific to PWAs, while my Quasar app is SPA.

Are there any pointers or examples how to achieve this?

Update: Somebody else posted this question on Stackoverflow a while ago, but no answer:
https://stackoverflow.com/questions/61546909/using-a-service-worker-in-a-quasar-spa

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