You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by GitBox <gi...@apache.org> on 2020/05/05 09:34:14 UTC

[GitHub] [openmeetings] sebawagner commented on a change in pull request #75: OPENMEETINGS-2344 Resize according to size

sebawagner commented on a change in pull request #75:
URL: https://github.com/apache/openmeetings/pull/75#discussion_r419980622



##########
File path: openmeetings-web/src/main/webapp/css/raw-tree.css
##########
@@ -24,6 +23,90 @@
 .file-tree .footer .sizes .size {
 	padding-left: 5px;
 }
+/* Calc width with default for max level of 7 */
+.file-tree .file.item .name
+	, .file-tree .file.item .name span
+{
+	max-width: calc(var(--room-sidebar-width) - 26px);
+	min-width: 60px;
+}
+.file-tree .tree-subtree .file.item .name

Review comment:
       I knew you would say that.
   
   But if you want a proper fix which is probably rewriting the entire tree so that:
   * the content resizes to the parent width by using DIV elements (not using span and making them block) 
   * have the icon on the right of the span, using flex + row in each line item. Not absolute position
   * use the ellipses for the text if not enough space cause by giving the span (inline) element no fixed width but putting it in between block elements. So that when it shrinks, it will shrink the span element as the only element that has no fixed width
   
   And if the width is goes beyond a minimum width:
   * change the tree to a plain list with some icons to save the space
   
   That is probably how you would fix it. If you do it "proper"
   
   So yes potentially my fix is technically its imperfect. I understand. You can't have endless number of tree-notes. 
   
   But do you want to rewrite the entire tree?
   
   Cause practically, if you go 7-levels down, there is no-way you will be able to see the file-name without resizing, cause the "cross" + indention + folder icons are already 7 times 18px = 126px. The user will not be able to see those files without making the sidebar bigger manually. And he probably will understand to drag the window until he can read it!
   
   So I think given the circumstances and not rewrite the component basic structure it is probably acceptable. Unless you want to rewrite the actual DIV and SPAN structure.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org