@Allan-EN-GB I’m in awe - in 152 lines of logic you achieved revelation in the weary world of frameworks and components. Your work is inspirational. Congrats!
https://github.com/quasarframework/app-extension-qribbon/blob/master/src/component/QRibbon.js
@nothingismagick said in how to insert image in editor wyswg?:
At any rate, we won’t be incorporating any 3rd party components into quasar core. The only way to do this would be to make an app-extension, and the core team is entirely swamped at the moment.
Funny, that’s exactly what I thought, and was surprised when you wrote about planned advanced WYSIWYG editor.
I will be needing tiptap in a few weeks. Firstly I’ll see how it works as a simple Vue component, but I would prefer to have it in AE version, because with AE you could deal with server/backend configuration (ie uploads, collaboration, endpoints). With AE mechanics, I will need some help. Will be in touch then. Thanks.
@nothingismagick definitely I could wrap that or help in wrapping, but I do not want to have three WYSIWYG editors in Quasar - old and simple, new advanced written from scratch by core team, and new AE based on tiptap and maintained by community. It would be counterproductive obviously.
@nothingismagick @adhityaramadian @donvie
Well, if you only want to embed base64 image than there is a simple solution for this editor in here:
https://forum.quasar-framework.org/topic/2019/how-to-insert-image-in-editor-wysiwyg/7
If there are plans to write another WYSIWYG editor from scratch, please consider wraping this excellent Vue editor as an App Extension:
@s-molinari said in Users of Firebase, I need your help!:
Um, @qyloxe - GraphQL is a bit more than your (sarcastic) example, because the query also forms the return result, which REST can’t do.
Well, both solutions are based on conventions. Nothing stops you from writing something like this in REST:
GET /api/v1/users/?fields=login,password
IMHO you missed a point - it is this “bit more” that is “quite more scary”.
To be clear, I’m not defending or praising anything - just commenting on IMHO quite controversial thesis about graphql and rest. There is possibility, that we think very similar, but are using different words 
For starters - there is no solution, be it graphql, rest, rpc, soap, …, which is “easier” or “better” on ALL levels of abstraction. You can not forget about complexity. You can only shift complexity from one place to another. And that is what “graph query language” does.
What IMHO are main pain points with graphql?
to be honest, it’s not the discussion I wanted either.
network routers rule #1: you can’t control what others say to you, you can only control what you are saying to them
In case of Firebase you also misdirected the point about vendor lock-in. It is not a simple vendor lock-in as: oh, I choose OVH, but I will be using my dedicated server, and my Postgres, and I use cloudflare as network frontend and configure my DNS elsewhere. Oh, and my logs, operations, billing will be processed in another application and the firm and the vendor is on my continent and I have a legal leverage with him because I signed a legally binding contract. No. In case of Firebase it is a TOTAL lock-in. Every piece of technology and operations is in control of Google. What is worse, that one problem with for example billing could disable all your other operations. There are so called “developer horror stories” with apps on play store or even youtube. IMHO if you are building a small/demo project than firebase is OK. Or if you are building a global application, and this solution is so big, that you have a legal and operational means to negotiate with google in case of problems (without them disabling your global solution for the time of negotiation as is a standard procedure in google haha).
@s-molinari said in Users of Firebase, I need your help!:
… GraphQL comes close in some ways from an API standpoint,
{ sarcasm mode on }
GraphQL is in essential this:
POST /api/sqlexecute?query=select%20login,password%20from%20users;
Quite scary. Firebase is this:
We know, that google is evil, aggressive, unpredictable and just a bully, but we try to believe, that firebase is different, that it could help us and always will.
This false belief is in real world called “addiction codependency”.
{ sarcasm mode off }
{ sad mode on }
we, as we developers are now (as in just now) building the world from the tv series “Years and years”. Highly recommended as a binge candidate.
{ sad mode off }
Well, firstly I’m quite impressed that they have a courage to say “classes doesn’t work for us - we tested them and js is a protype based so we will use that”. I have a similar feeling, that using classes in JS is a cancerous concept from Anders Hejlsberg, who sadly by last 30 years tries to put those simplistic delphi 2.0 style views on every technology that he touches.
In the context of Quasar, I assume, the biggest clash of ideas/potential for improvement will be in the app extensions. This is very similar concept because Quasar needed a way to extend itself on many levels of abstraction. With the new function based component setups I assume it will be possible even without app extensions. As for now, it is at the RFC level, obviously they see the problem. As for now, I trust them because, they saw the future in the past, and that’s why I started to use Vue. I have a feeling, that with those new concepts, they see the future again.
@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.
@digiproduct here are quite mind boggling benchmarks about backend API frameworks:
https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=update
in “data updates” test, laravel is placed at 186 position
let the backend frameworks wars begin ha ha ha (evil laugh)
It’s always better not to reinvent the wheel. If you need advanced editor interaction, maybe this one helps: