No More Posting New Topics!

If you have a question or an issue, please start a thread in our Github Discussions Forum.
This forum is closed for new threads/ topics.

Navigation

    Quasar Framework

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    provide traditional layout for slider

    Framework
    3
    5
    143
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      dgk last edited by

      A request:

      True I can make yet another component but can quasar support the ole traditional spinner within the slider component? As far a api could be as simple as adding a boolen prop to display slider as the good ole traditional “spinner”. The props otherwise would be much the same, max min, etc.

      This wouldn’t be a breaking change just an optional style prop to the slider api.

      01585574-6193-428d-bf89-7411a229dd23-image.png

      1 Reply Last reply Reply Quote 0
      • D
        dgk last edited by

        easy enough to use this one. Still would be good if q-slider had this spinner appearance.
        https://vuejsexamples.com/a-customizable-number-input-spinner-component-for-vuejs/

        1 Reply Last reply Reply Quote 0
        • rstoenescu
          rstoenescu Admin last edited by

          But it’s sooo easy to make one yourself. Just use the prepend and append slots… and you can even add TouchRepeat directive on the slots (be them buttons or icons or… whatever) 🙂

          1 Reply Last reply Reply Quote 0
          • D
            dgk last edited by

            Ok sure I can extend as I have done with select slots but with a PR you would not incorporate this? This would not be a one off (for me). Would like that added functionality as part of a quasar base form components. Slider component as is not a great one for mobile/touch (spinner with big buttons and touch repeat so much easier)

            Alternatively the quasar project could make it easier to import/use project/community “extra” components. The featherjs project makes that pretty easy (like with common hooks library). Maybe this is already happening just unaware.

            Like the current quasar extras maybe a quasar vetted component “extras” repo/module. Submissions would abide by some criteria and the component would be vetted by a project member or experienced community member. Then if package is installed the components therein can be loaded via quasar.conf.js just like the main component library (all, manual, auto) instead of one off in code as would be the case currently.

            qyloxe 1 Reply Last reply Reply Quote 0
            • qyloxe
              qyloxe @dgk last edited by

              @dgk said in provide traditional layout for slider:

              … Maybe this is already happening just unaware.

              I believe AE (app extensions) are the way to go:
              https://github.com/quasarframework/quasar-awesome/blob/master/README.md#community-app-extensions

              Why? well, quasar is opinionated at the framework level and flexible at the library level. This is where confusion comes from. Including community extensions at the core would be bad because lib level flexibility means chaos at the framework level. We could elaborate, but let’s assume that it is.

              The “components” at the framework level are called “components” or “plugins” or “…”, but they really perform a role of “solutions”. You can “incarnate” those solutions and make your own “components” which are truly reusable. Just as you can have a “solution” of power engine and incarnation of this engine in a truck and a realisation of this incarnation in a truck in your garage (a final application).

              We should not mix solutions with libraries with applications. App Extensions in Quasar are at this specific moment of time excellent, because they allow to quite safely extend not only visual parts of framework but also behavioral and structural parts of the whole Quasar (generator, optimizer, library, etc.). We do not know now what is “best” or is “preferred”, this will come with time and patience. BUT if we will close our understanding of Quasar ecosystem with some specific solution with our current understanding and current needs, it will surely close many future possible Quasar applications.

              What we will probably should do, is to wait for the bigger ecosystem of app extensions, and let them live, divide, mutate, and from that we will know what boundaries are necessary. I opted for one for AE with many visual blocks for theme developers, you are talking about specific interactive components family for selection, others want drag’n’drop, others wants integrations with backend or auth solutions. Quasar is BIG idea and just a thought that it creates all those needs in people minds should tell us how BIG the Quasar (as a concept) really is.

              1 Reply Last reply Reply Quote 1
              • First post
                Last post