[v1] QDate & QTime does not have ok/cancel button to dismiss the dialog
metalsadman last edited by
can’t complain, but many features removed which is kinda sad, i don’t understand the regression. gotta stick to 0.17 for now or back to native.
s.molinari last edited by s.molinari
I would guess the decision to pull back on features is because with too many features added, a framework actually paints the devland devs into a corner. Yes, many will like the features being there, like everyone here asking for them. But, a lot more will want something different. If a framework has given a certain feature a certain way, it’s then “baked in” and it’s hard to change or customize. So every request after making that feature for something different has to be ignored or we have to tell developers, “It is what it is. Lump it or like it.” Or, the feature is changed and we have feature churn. All of that can and most likely will be a source of frustration for everyone.
A framework should make smart decisions for developers. It shouldn’t make all of them and not even most of them. If you want a system that makes a lot more decisions and does a lot of the work for you, then you either need a framework that offers extensions (like Quasar), where devland devs share their “decisions” and work with others. Or, you need to find a platform that uses Vue and makes a ton of decisions (and does a lot of work up front) for you. Vue in and of itself is also built with the extensibility idea in mind. Vue CLI and plug-ins is ingenious and a step above what React has.
Quasar has taken a parallel track to Vue’s extensibility now.
And, a platform hasn’t been built yet on Vue, and yes Quasar, with a good bit of work and a lot of additional decision making, could become a platform too.
[upvote this issue]
Someone find a sollution allready? It is annoying that the QDate-dialog does not close after selecting.
<q-popup-proxy ref=“qDateProxy” …
is ugly and, indeed, close the dialog at year or month selection.
This is kind of hacky however I used the following although this uses a dialog instead:
<q-dialog v-model="date"> <q-date v-model="post.date" today-btn @click="date=false" /> </q-dialog>
Yes, a quick and dirty workaround…
It’s such a normal and predictable kind of functionality… it should be a property of the component: ‘closeonselect = [true/false]’…
It will be better to emit an ‘input-date’ event for only date so that we can close popup-proxy on that event. Currently event name ‘input’ emitted for all three selection( i.e. ‘year’, ‘month’ and date) so we can not guess that user has selected final date to close date picker.
@s-molinari its not happening in v1 for code below
<q-date minimal v-model=“date”/>
cick0 last edited by cick0
The Input event provides enough detail to customize when the dialog gets closed:
@input -> function(value, reason, details)
I use ‘day’ and ‘today’ to close the dialog.
Thanks @s-molinari for the pointer as to which component to hide (proxy). I was trying to hide the date component in vain.
I’m a beginner and I’m in trouble, can you help me?
Inside v-for q-popup-proxy does not close.
s.molinari last edited by
Create a new thread @fpchagas
I can’t seem to get hide() to work, but what’s working for me is… (although I’m using q-popup-edit)
<q-popup-edit ref=“popupStartDate" v-model=“props.row”
<q-date v-model=“props.row.startDate” @input="$refs.popupStartDate.set()"
Also took me some time to realize that if I set the v-model in the q-popup-edit to the same as the v-model in the q-date, the value would immediately change back to the original value after selecting it.