@s-molinari said in Did you get support from the Quasar Dev Team or the Community?:

… And, we only can help during or own free time, so there isn’t any SLA to answer within 24h or the like. To be honest, the attitude you seem to have about OSS and how it should be “supported” is out-of-place.

just a thought - I always believed that it is we, who has a duty to support the open source authors, help them, be kind to them and praise them - not the other way around! It is they, who give something for free, something most valuable in their life - their time. It is they, who create something instead just consume as most others. Just $0.02 here.

@rstoenescu @s-molinari

Hmm, as an unfortunate author of this charming “solution”, please take my advice and do not incorporate this trick/hack at the framework level into Quasar. Yes, it looks nice in developer eyes, but it is valid only in specific situations and taking it out of the context of the whole typography would be IMHO more hurting to the image of Quasar as a CSS web pages platform.

Why?

1. Typography is about visuals, rhythm, beauty, composition. This hack is an algorithmic take on font sizes and it is linear in nature. In reality, the scaling of visuals should be non-linear and adjusted to the page purpose, specific font etc. If we will encourage designers considering Quasar as their next tool, to use linear design (at the framework level), they will laugh us off. It should be a developer decision if he wants to use linears in his specific web page.

2. Yes, it is only part of “typography” as a whole and it is rather crippled part. The more advanced take to font scaling (only) at the LIBRARY level is here:
   https://github.com/twbs/rfs
   If at the APP level, one would want to use this LIBRARY, then one would only need to:

npm install rfs --install

and in their app.styl code:

@import "../../node_modules/rfs/stylus";

Why is it encouraged to use this library and not incorporating anything into the framework? It is not recommended because you lose the ability to easily and quickly manage and update RFS as a dependency. Why is it important? Because for example “my” solution doesn’t work fully on safari browser. There are specific quirks which this library handles and my hack does not. There is a documentation of how and where use or not to use scaled fonts (not on HTML tag).

1. Why typography is so important on web pages (and even on web apps)? What is this typography anyway? Well, there are so many tutorials, books and knowledge. Those are interesting at the beginning:
   https://css-tricks.com/typography-for-developers/
   This one touches of the tip of the iceberg - rhythm:
   https://www.webfx.com/blog/web-design/css-typography-02/
   There is a beautiful parable - I’ll cite “The concept of vertical rhythm is simple: Line heights, margins, and padding should all be equal or within even proportion.”. Even if a daveloper knows how to use CSS typography properties (so many…) does she understands what rules needs to be followed and which ones could be broken?
   This is nice one too:
   https://practicaltypography.com/
   … and many more.

2. What can I do anyway? Well I’m strongly encouraging to somehow incorporate Bootstrap design concepts into Quasar, but not necessarily at the framework level, but rather as friendly agreement to “not reinvent” Quasar own solutions, in a way, which would prevent using of knowledge and solutions accumulated in Boostrap as a concept. As I said in previous posts, the key is to convince thousands of developers from Bootstrap to convert to Quasar.

3. Can I use Boostrap already in Vue and link it with Quasar? There are solutions at the Vue level for example:
   https://bootstrap-vue.js.org/
   https://medium.com/@BjornKrols/integrating-and-customising-bootstrap-4-in-vue-js-cbc29ba7688e
   But they won’t be rather compatible with Quasar, because Quasar, at the framework level, intentionally or not, is using similar CSS classes to Boostrap, and it would just make a mess if one would want to use those two CSS system at the LIBRARY level.

4. Why am I differentiate “framework”, “library” and “app” level? At the framework level there is an “inversion of control”, at the “library” level it is the “app” who decides where “control” is, and the “app” is where the “interaction” is. Without “interaction” there is only “web page”.

5. OK, so what are the options to play along with Boostrap4 in Quasar? Quasar is based on “material design” and Boostrap is not, so why we even are talking about that? Because the most important are those designers/developers to convert and thousands of web page templates and snippets to use. We do not need to USE the B4 as a base for Quasar, we only need to have “possible way” to use hard learned B4 skills in Quasar environment. It is sufficient for Quasar not to prevent this (as it is doing now). Have it be done in Vue? Yes, there is a project MDBootstrap - “Material Design with Boostrap in Vue”:
   https://mdbootstrap.com/docs/vue/
   The name is perfect, becuase this project, as it is claiming, converted 800 000 developers to using Bostrap in Vue! This is the scale of traction we are talking about.

6. How is it possible for this project to be this successful? It allowed to use B4 skills and promised to multiply the productivity by using Vue. This project is focused on presentation, which is Quasar weakness. If Quasar would incorporate some of the design elements/concepts/ideas from MDB, than because it is a superior FRAMEWORK it would just offer a win/win.

7. In essence - we really do not need to follow the path of manually dealing with every css typography property or scaling or visual specifics. It is Vue and it is 2019. The MDB project has something like “Sections”. Please take a look:
   https://mdbootstrap.com/docs/vue/sections/demo/
   This is what we (as “we” developers") need at the end of the day: the highly configurable web page compound elements, with superior layout, excellent typography, visually atractive and highly configurable sections of blog, contact, e-commerce, features, intros, magazines, projects, social, teams, testimonial, and of course, jumbotron. With those “bricks” the Quasar would not only be an excellent app platform but also web page platform. In MDB those sections are highly compatible with B4 semantics and this is why this project is so succesful at developer acquisition. In MDB they are manually converting those web templates and snippets (but it is possible and it is simple), in Quasar we just could write something to automatically convert existing B4/MDB templates/snippets (ideally of course).

8. What am I proposing? There is a concept of App Extensions in Quasar. It is just ingenious. What we need in V1 is to not overwrite CSS classes from B4 (which would allow to use some of the B4 concepts) and make an App Extension with default sections for web page developers (maybe even the same as in MDB - they’re great). There is a twist - in specific demos, there should be examples of incorporating Quasar app components in those sections! It would be just a killer feature for thousands of developers. They couldn’t resist the temptation to finally use something app centric on those boring web pages, they are making every day, just to bring some food on the table.

As a learning project I created a repo with BEX technology, as of now, it can interact with specific page, inserts some DOM and propagate events from host page to BEX, persists data between page changes, executes some privileged operations and some more stuff.

This is a learning/testing project. I would GLADLY donate this repository to Quasar devs as an example of BEX awesome technology. It is a starter of course, but it looks interesting. We as a developers alway like examples and code ready for copy/paste, so such projects will be useful.

This is the repo:

https://github.com/qyloxe/qbexlinks

In readme.md there are some questions, I think the main problem is why this doesn’t work in Firefox and how can w debug/test this on Mozilla platform. Unfortunately Chrome is better in this, there are more meaningful error messages for example. It worked in Firefox at the beginning but after changes to manifest.json and maybe in some other places it stopped working.

Firefox is important IMHO because it offers a sidebar technology for BEX. In Chrome there is no sidebar unfortunately.

All questions and comments are welcome. PR or anything on Github even more. Happy coding!

@rstoenescu said in fluid typography - SOLVED:

… Quasar is looking into the future and sets its own high and modern standards. And yes, in order to make progress in web development you need to break the current establishment. Otherwise we’d all be continuing to write websites in cgi-bin / perl today too, because maaany years ago that’s what developers were accustomed to. And what most developers are accustomed to at one point in time doesn’t actually mean it’s the best solution or the “definite” solution, and Quasar will never bend into choosing what we believe is not the optimal path to high quality work, not even over money.

We now have limited resources, but if you take a look at what has been achieved here then imagine what we can do with proper resources. What I want to achieve with Quasar is to raise the bar for web development as a whole. Make it go forward, evolve. Change minds. Point out when there’s a better alternative.

Please, please put above words somewhere on the main page. This is so strong, power and emotional narrative. Pure energy which leads and shows the new way to people. I’m in awe of those words, you used so many emotional and strong terms in such a short content. Almost like a poetry, but for developers Please, use those words not only on this forum but for rest of the world to hear. They deserve it.

App Extensions - one of the most ingenious and powerful of all Quasar concepts. I want to ask what is your vision about their role in the future Quasar architecture? They’re great and they’re powerful, yet they’re quite cryptic and there are not too many of them. Do you want to let devs create them more? As for now, IMHO there is a confidence gap between their docs, usage and “marketing”, so average developer could have a problems to just trust AE subsystem and learn it and create something with it. There’s no confidence, that it is a recemmended “Quasar way” of thinking.
Do you see them as a playground for wizards and when their toys mature, they should be incorporated into the Quasar core (icongenie) or rather as a system for Quasar openness and integration and also - very important - as a market (in business terms) for thousands of custom AE? If it is latter, maybe it would be a sign of confidence to just convert all existing quasar components into app extensions?

@DDP said in Drag And Drop:

Upvote for built-in draggable features, especially for lists and tables

and q-tree and q-chips…

Scenario:
Let’s assume you are building a typical (business/product/blog) webpage with Quasar. You want it to be flexible and responsive and VERY mobile friendly and VERY big screen friendly. After a while, you realize it is very hard to achieve with Quasar. Almost impossible out of the box. In normal scenario you would use one of the thousands Bootstrap site templates, BUT, in this case you are just stubborn to use Quasar.

One piece of the puzzle is fluid typography:
https://www.madebymike.com.au/writing/fluid-type-calc-examples/
https://css-tricks.com/books/volume-i/scale-typography-screen-size/

In Quasar you could use something like this in your app.styl file:

fluid-font-size($minimumSize = 12, $maximumSize = 36, $minimumViewportWidth = 300, $maximumViewportWidth = 1600)
  font-size: 'calc(%spx + (%s - %s) * ((100vw - %spx) / (%s - %s))) !important' % ($minimumSize $maximumSize $minimumSize $minimumViewportWidth $maximumViewportWidth $minimumViewportWidth)

for num in (8..28)
  .fontsize-{num}
    fluid-font-size num (num*2+2) 300 1800

The code above will generate CSS classes fontsize-8 through fontsize-28. After that it is quite simple to use it like this:

<p class="fontsize-10"> this is content text</p>
<p class="fontsize-12"> this is caption</p>
<p class="fontsize-14"> this is header</p>
<p class="fontsize-16"> this is bigger header</p>

In similar style other CSS typography properties could be scripted (line-height etc.). I know, it is not ideal, I would strongly prefer to have something like responsive/fluid typography CSS system in Quasar itself, but for now - it just works.

Quasar is awesome! (it means you guys are awesome)

Found this little gem. Thought it might be helpful to somebody:

https://instadeq.com/blog/posts/things-end-users-care-about-but-programmers-dont/

I would love to have that integrated into Quasar:

https://github.com/scrumpy/tiptap

look at the examples - “suggestions”

I assume you will have to deal with such categories of files:

CS- shared code
CC- common code
FS- shared configuration
FC- common configuration
DS- shared data
DC- common data

my hypothetic folder structure (lets assume windows) would look like this:

/bin
  client01_dev.cmd
  client01_build.cmd
  client01_cicd.cmd
  client02_dev.cmd
  client02_build.cmd
  client02_cicd.cmd
/conf
  /common
    app.json
    servers.json
  /client01
    secrets.json
    params.json
  /client02
    secrets.json
    params.json
/data
  /common
  /client01
  /client02
/dev
  /client01
  /client02
/dist
  /client01
    /spa
  /client01
    /spa
/src
  /project01
  /sharedlib01
  /sharedlib02

in /src I would have git clones for main branch of project and every shared submodule. Eventual changes in client forks/clones would be merged/rebased here. This main git repo would keep releases of your app.

in /dev I would have git branches for every client with shared code as git submodules.

in /data/common I would keep all common data (files, images, sqlite databases etc.)
in /data/client[xx] I would keep only specific client data.

In /conf/common I would keep shared configuration ie app parameters, server data etc.
In /conf/client[xx] I would keep specific client parameters - smtp passwords, ssh, this client app conf etc.

In /dist/client[xx] I would keep the result of quasar build and other files copied after distribution command (environment, statics). The files from this folder should go to server or be a source for continuous integration/delivery.

in /bin I would have build/dev/dist tools for every client:
client[xx]_dev.cmd
this tool is for developer. depending on dev model it could take code and data from git, it could properly build configuration/environment data, npm/yarn and of course run “quasar dev -m spa” command in proper client directory.
client[xx]_build.cmd
this tool should run a command “quasar build” and the client project will be compiled into proper /dist/client[xx]. then there will be copied there specific client configuration files and data files - and of course - common data and common configuration
client[xx]_cicd.cmd
this tool should distribute your app to production in whatever means necessary

Whats in /dev/client[xx]?
This is a quasar project, with .gitignored specific .env file, with highly modified quasar.conf.js. In /dev/client[xx]/src there are git submodules with shared code. The modifications to quasar.conf should take parameters from client[xx]_dev.cmd and client[xx]_build.cmd and act accordingly. For example it could take a path to configuration files and prepare this clients .env file or put some data into build.env quasar.conf.js section. It is also possible to use custom webpack configuration here and just copy some common or shared client files during the dist phase.

Well, thats the gist. The main pain point with this workflow is of course git management, but I doubt that with such specific assumptions of client separation/multi tenancy, any other solution would be less painful.

App Extensions - one of the most ingenious and powerful of all Quasar concepts. I want to ask what is your vision about their role in the future Quasar architecture? They’re great and they’re powerful, yet they’re quite cryptic and there are not too many of them. Do you want to let devs create them more? As for now, IMHO there is a confidence gap between their docs, usage and “marketing”, so average developer could have a problems to just trust AE subsystem and learn it and create something with it. There’s no confidence, that it is a recemmended “Quasar way” of thinking.
Do you see them as a playground for wizards and when their toys mature, they should be incorporated into the Quasar core (icongenie) or rather as a system for Quasar openness and integration and also - very important - as a market (in business terms) for thousands of custom AE? If it is latter, maybe it would be a sign of confidence to just convert all existing quasar components into app extensions?

@mark said in How can I conditionally include/exclude pieces of my app?:

Our current solution is to use protected routes so that the client can only view what they have permission to view, however the shortcoming here is that the inaccessible sections of the app (be it files/components/folders) are still in the bundle itself. We would like to have the option to ignore these files/components/folders on build. Is this possible?

I would consider the option of git branches for those clients (hoping there are not too many of them). If this is not feasible with scale, then there are git submodules and clever build options for those files/components/folders. Anyway, git is the first what comes to mind.

@s-molinari sure, good idea!

I want to ask about drag’n’drop support in Quasar components. It would be nice to have q-tree with drag and drop, or q-table with repositioned columns and rows, or q-list which could exchange items with other components.

@Ben-Hayat said in Desktop Template & Mobile Template both in the same page?:

… I’m missing something, it does not address where different templates (i.e. Mobile or desktop), each needs to have their own set of Quasar components. For Example, for Mobile template, I might use a simple DataTable with 3 columns but in desktop I might use a different DataTable to show parent/child data with more columns. In Desktop I might not offer certain complex features (using components) to user, where in desktop I will.

It addresses exactly that by using slot sufixes - -mobile and -desktop. In example above you have a simple embedded svg image in mobile (need to fill the valid code in your head of course) and in desktop this static part of the section has a carousel/slider with lots of images (also need to imagine that).

The section designer should decide what slots are needed and how to present them. I just want to fill the content - maybe even with other sections (as in above example I’m filling the content slot of section-title-with content, with the component section-image-content).

Bear in mind, that in reality you do not only have “desktop” and “mobile” targets. There are more - for example in most mobile browsers there is a mode called “show as desktop site” which is just … different … from both mobile and desktop.

@Ben-Hayat said in Desktop Template & Mobile Template both in the same page?:

@qyloxe
I 'll be taking two approaches.
For responsiveness and auto arranging, I’ll design it as “Mobile-First” as default and then add proper CSS for other sizes.

In ideal world I would use something like this:

<section-title-with-content>
  <template #title-mobile> this is shorter, mobile title
  </template>
  <template #title-desktop> this is much longer, decriptive, desktop title
  </template>
  <template #content>
    <section-image-content>
       <template #image-mobile>
          ... some optimized mobile image in svg ...
       </template>
       <template #image-desktop>
              ... in desktop it could be carousel/slider...
       </template>
       <template #content-mobile>
           ... here is a copy for mobile users....
       </template>
       <template #content-mobile>
               ... here is a looooong text for desktop oldtimers...
       </template>
     </section-image-content>
  </template>
</section-title-with-content>

I do not want to use if-s, or manually decide css breakpoints. I want declarative, easy to use, always beautiful blocks

Agree with @s-molinari it is rather budget/team/resources dependent BUT if you want do JUST decide desktop-first or mobile-first I encourage to look at existing site logs/stats/analytics. In every major website I know, as for now, it is about 80% for mobile and less than 20% for desktop. Desktop is declining.

Of course we are talking about website or simple web app, but not about full app, pwa or mobile/desktop app.

We talked about it long time ago as I remember - well, ideally we would have in Quasar a set of presentation components like “page with image on the left and content on the right” or “page with big title and three sections on the bottom” or “page with carousel with sections with title, image and simple content”. Those component would just KNOW how to present themselves on desktop/mobile and a designer could build her site from those blocks filling content only. As for now, there’s no such library of visual components for Quasar framework. We talked about it when compatibility with B4 was discussed.

Different philosphy. You talking about declarative code but q-table is more imperative, you need to specifically tell the framework what you want. It is better suited for data-bound apps (api, slots, ect.) than visual representation (static html struct, clean hierarchies), as you can see. There’s no problem to build another suite of components highly declarative only for presentation. In fact, in quasar you can use declarative css table classes in “normal” html table code (table, td, tr, th etc.) and it will look very similar to q-table.

@walfin said in How many people use NetBeans?:

@qyloxe I’m trying out VSCode now as I am beginning to hate the NetBeans startup lag and lack of support for STYL.

I find the intellisense when using JS (not TS) worse than NetBeans (it gives prompts for lots of useless stuff in the dropdown menu), I hate the auto tag closing (which sometimes screws up my code) and I’m not used to the git interface (it doesn’t popup a commit box, and also I can’t figure out how to find a place where I can view the entire history tree of the repo). And the outline box doesn’t work for my JS files (unlike the navigator in NetBeans).

yep, most of the problems you mention are a matter of configuration/proper extension/ssd drive For example this extension gives nice git graphs:
https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph
There are tons of extensions so as we can see in this topic - everybody likes something slightly else. I would hate a world, where everyone had to live and work the same way.

@necmettin said in Anybody tried out Svelte framework yet?:

@s-molinari said in Anybody tried out Svelte framework yet?:

You can’t do anything with Svelte without its compiler.

How is this an argument? Svelte IS the compiler. The counter-argument would be “You can’t do anything with Vue without the Vue framework.”

I believe he meant the distribution options of Vue. You can use production Vue in “runtime” mode, or in “full” mode - with Vue compiler. More here:

https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds

IMHO argument stands. Not that it matters, but technically it is valid.