You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to increase the contentchooser height in a Plone site. The size is now hardcoded and only shows 9 items, where the whole contentchooser height is less then half of the web page hight. Ideally the contentchooser dialog would look at the available screen height before it pops up and set itself to 2/3, but overriding the height to a new fixed size would be an easier alternative.
Issue: in collective.cover the resizable feature of the contentchooser is only limited to horizontal, and when you try to change the horizontal width the dialog make a vertical jump and the internal dialog elements also get distorted a bit. So the internal markup of the contentchooser (no longer?) supports resizing.
I have found two places so far in the code where the dialog dimensions are controlled: contentchooser.js
The current values seem to be misaligned because of the resizing issues. I could override the values in both locations to make the dialog bigger and I'd probably remove the .resizable at all because the contentchooser markup doesn't seem to support it. But I'd have to overwrite two resources files, which are both in a resource directory and cannot be overridden using z3c.jbot.
Adding an automatic resize function on popup depending on the users screen height would require making the contentchooser height-flexible which it now isn't and requires front end skills I don't have :-(
This is also a bit related to issue #752 about refactoring covers' css/js, if that is considered can we at least register the most important resources as individual resource registrations which makes it much easier for an integrator to override a single resource in zcml?
The text was updated successfully, but these errors were encountered:
yes, the content chooser is a piece of crap that we need to refactor ASAP; we're finishing an important project and we can't help until 2 or 3 weeks on this.
do you mind to make a list list with all the enhancements that you would like to see here (besides compatibility with Plone 5)?
I would like to increase the contentchooser height in a Plone site. The size is now hardcoded and only shows 9 items, where the whole contentchooser height is less then half of the web page hight. Ideally the contentchooser dialog would look at the available screen height before it pops up and set itself to 2/3, but overriding the height to a new fixed size would be an easier alternative.
Issue: in collective.cover the resizable feature of the contentchooser is only limited to horizontal, and when you try to change the horizontal width the dialog make a vertical jump and the internal dialog elements also get distorted a bit. So the internal markup of the contentchooser (no longer?) supports resizing.
I have found two places so far in the code where the dialog dimensions are controlled: contentchooser.js
collective.cover/src/collective/cover/static/js/contentchooser.js
Lines 356 to 361 in 9b624dd
And the height of the item-list influences size of the dialog in
collective.cover/src/collective/cover/static/css/contentchooser.css
Lines 33 to 44 in 9b624dd
The current values seem to be misaligned because of the resizing issues. I could override the values in both locations to make the dialog bigger and I'd probably remove the .resizable at all because the contentchooser markup doesn't seem to support it. But I'd have to overwrite two resources files, which are both in a resource directory and cannot be overridden using z3c.jbot.
Adding an automatic resize function on popup depending on the users screen height would require making the contentchooser height-flexible which it now isn't and requires front end skills I don't have :-(
This is also a bit related to issue #752 about refactoring covers' css/js, if that is considered can we at least register the most important resources as individual resource registrations which makes it much easier for an integrator to override a single resource in zcml?
The text was updated successfully, but these errors were encountered: