-
-
Notifications
You must be signed in to change notification settings - Fork 566
XWIKI-23286: Panel toggles and handles inconsistencies #4140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Changed the nature of the hint fgor panel toggles. * Added controls on the standalone edition sheet. * Made sure everything that worked with rightPanels also works with editPanels.
* Fixed the solution for the edit button. It triggered the form unexpectedly... * Updated the styles to keep them clear * Updated the visibility of panels to always be shown when the device has not enough width.
* Fixed the unexpected side margins in mobile mode. * Prevented resetting preferences for panel width when passing by a page without panels.
IMO it would make sense to assign this PR to the 17.4.0-RC1 release manager. |
@surli Let me know if you'd rather have the CI fix in its own PR so that we can merge it asap. |
|
||
& #leftPanels { | ||
display: none; | ||
/* We hide panels only when the screen is small enough. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit puzzled by your comment. The media query below is activated when the screen width is larger than @screen-md-min
, so my understanding is that the screen must be large enough. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was in order to fix when I hide a panel and then switch to "mobile mode" by making the window smaller, the panel stays hidden but there is no more button to get it back?
I;ll try to word it better because it even took me a while to understand again what I was doing here ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 6f5ff42 👍
Did you check also in |
https://github.com/search?q=org%3Axwiki-contrib+%22editPanels%22&type=code&p=2 There's quite a few styles that would get lost when migrating. About half of those seem to be coded specifically for the editPanels while the other half also impacts the We could discuss about it further, but I'm not really a fan of all these alternative classes we use in the edition template (non inline edition). IMO it's enough for CSS to have one or a few extra classes on the top level container (either body or the edit form) to describe that the page is in an edit state . Right now, the whole structure is different from a view page while it's --for the most part-- the same layout and UI. So we have a lot of duplicated styles or unecessarily rare selectors. |
It's not only about styling. For example you have: https://github.com/xwiki-contrib/application-xwebide/blob/7bda93596a03f4c95f4abc5e921a5f6e13e4da20/application-xwebide-ui/src/main/resources/WebIDECode/WebIDE_class.xml#L469 and the extension is not indicated as deprecated or not working: https://extensions.xwiki.org/xwiki/bin/view/Extension/XWebIDE+Application |
Warning TBD when writing the release note for this commit if we don't change solution: Let people know about the change in ID.
AFAICS we don't have much documentation about it. Nothing on https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/FrontendResources/ . The only mention of this class I could find in our doc was: https://design.xwiki.org/xwiki/bin/view/Standards/CSSAPISelectors . We can keep this specific ID, but then we need to make sure that we describe it as API in the doc then. It comes with a non-null maintenance time and we should push people to use this one to power their customizations and extensions. I opened a topic on the forum to discuss it with everyone,. |
The consensus from the forum was that it was okay to remove |
* Updated the comment to be clearer
Addressed all comments and created a new issue (because the fix didn't get merged with the cause in 17.4.0) XWIKI-23286: Panel toggles and handles inconsistencies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me apart from a tiny code style issue, but I haven't tested if this actually resolves the problems.
...flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/flamingo.js
Outdated
Show resolved
Hide resolved
* Fixed codestyle Co-authored-by: Michael Hamann <michael@content-space.de>
* Removed an unwanted change added mistakenly at conflict resolution
There was a small conflict with the changes merged from |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
Jira URL
I gathered a few fixes to small issues that are related to the new panel column controls.
Let me know if you think it's important to split these fixes across a few PRs.
This PR contains fixes for:
Changes
Description
Clarifications
#editPanels
. However, this was pretty much just duplicating CSS selectors everywhere (difficult to maintain). So I checked the actual uses of the#editPanels
id. In XWiki Standard, it was not used in any selector. I figured it was okay to change this ID, and reverted all the selector copypaste I made in favor of this ID change.Screenshots & Video
2025-05-07.14-57-53.mp4
Executed Tests
Manual tests to check all the points mentionned, see above for some of them.
Successfully built:
mvn clean install -f xwiki-platform-core/xwiki-platform-web/ -Pquality
mvn clean install -f xwiki-platform-distribution/xwiki-platform-distribution-flavor/xwiki-platform-distribution-flavor-test/xwiki-platform-distribution-flavor-test-webstandards/
Expected merging strategy