Thank you for your answer Florian,
But as I wrote before it's all solved form me, but I'm trying to
convince others that this is a use case and may be implemented in the
core ui.
I've additionally created decorators which visualize the readonly state
for textarea, textfield, combobox etc. to a
I don't know if this works, but IMO you could try it. Why don't you
simply not bother with editable/readonly at the level of each
individual form element, and just put a blocker with opacity == 0 on
top of the form when it has to be read-only? IMO this also provides a
nicer separation of concerns/s
I've just checked
http://demo.qooxdoo.org/devel/demobrowser/index.html#ui~FormInvalids.html
and I still think the readability is poor on disabled state (by pressing
the disabled button in the demo).
This changes a little bit from theme to theme from indigo being less
readable to modern being be
Hey,
> Anyway I still see the use case for this: disabling checkboxes and
> radiobuttons puts a gray haze over the widgets, including their
> labels, which makes them poorly readable. The user should have good
> readability and the visual representation of the "value not changeable
> but readable"
Thank you Martin and Andreas,
I've allready implemented what Is needed for my purposes. I've
implemented readonly states in my themes appearance part, created the
readonly properties for check and radioboxes, inhibited focusing. The
last part is still missing: icons (for the aristo theme) which
vi
Hey,
I agree with Daniel in closing the bug. A read only checkbox is a disabled
check box. I think the user should see and know that he can not change the
value but he can read it. Thats the basic idea of the enabled property. If you
think different, you might either change the theme of the chec
gt;Von: Dietrich Streifert [mailto:dietrich.streif...@googlemail.com]
>Gesendet: Montag, 26. November 2012 13:57
>An: qooxdoo-devel@lists.sourceforge.net
>Betreff: Re: [qooxdoo-devel] CheckBox fields and readOnly
>
>Hello everybody!
>
>Daniel closed the bug report for lack of use cas
Hello everybody!
Daniel closed the bug report for lack of use cases.
Here is our use case:
We have a huge qx.ui.form.Form and renderers based on
qx.ui.form.renderer.AbstractRenderer with a lot of radiobuttons and checkboxes.
The resulting rendered form widget is used (via model, controller et.a
I added a bug report for this, as an enhancement
Bug 6051
Regards
Le 17 janvier 2012 10:31, Benjamin Dreux a écrit :
> But then why mimick the readOnly behavior ?
> IMO since textField can be readOnly, the other form field have the
> same behavior.
> It will facilitate the understanding of the u
But then why mimick the readOnly behavior ?
IMO since textField can be readOnly, the other form field have the
same behavior.
It will facilitate the understanding of the ui framework.
Le 17 janvier 2012 10:21, Daniel Wagner a écrit :
> Hi Benjamin,
>
> I don't know for sure, but my guess is qoo
Hi Benjamin,
I don't know for sure, but my guess is qooxdoo is mimicking HTML, where
the 'readonly' attribute is only supported on text and password input
elements.
For checkboxes and radio buttons, there's the 'disabled' attribute, the
qooxdoo equivalent of which would be the 'enabled' propert
Hi
I just went throu the documentation of the checkbox class
(http://demo.qooxdoo.org/current/apiviewer/#qx.ui.form.CheckBox)
I discovered that there is no property readOnly.
The documentation of qx.ui.form.Textfield says that this property
(readOnly) come from abtractField.
I wondering why ther
12 matches
Mail list logo
