New design CSS

[fabriceci]

@servocoder I started today to code a new theme for the manager. I would like to have your opinion on in few points and your help on few modifications. Maybe it will be simpler to discuss a day into an online chat (or here if you prefer)?

[psolom]

Let's try to do it here. Themes have not been discussed before and it may be useful to write down some ideas here.

[fabriceci]

I'm not a designer so I tried to make improvements on the fly.

I saw that the themes are just an overload of the base filemanager.css. I don’t like this because it’s not flexible, you should cancel all properties you don’t need.

So I started from scratch with sass.

To be flexible, I split css in multiple file and added one with variables. Like this it's very easy to build a custom theme. (change colors, fonts, etc.)

There will be a light theme and a dark one. They are responsive, for now the light theme looks like this

I only make changes in the index.html file and I kept the tags structure (even if tags need a refecator to be more flexible/consistent).

I'm not comfortable for now with the JS, so I don't want to make changes for now that.

I need your help, if you are interested, for the implementation of the breadcrumb in the JS @servocoder. I think it's an ergonomic way to move into folders (and more beautiful).

What do you think about that?

I will make another answer to points of discussion.

[psolom]

Wow! I'm not a designer too, but it looks nice for me :) Saas is a great idea, that is what I also planned to implement. I also like your idea about breadcrumbs, and it's good that you haven't changed JS because I'm currently performing a lot of changes there. You'd better wait with any JS changes until the next release on the "dev" branch. I will gladly help you with that. I need to know which changes you have made in html file, especially the representation of the breadcrumbs html.

[fabriceci]

Ok great, we could finish that after your changes!

I will fork the dev branch and add my modifications at the end of the week (you will be able to test/see easly).

For the breadcrumb is just an ol :

<div class="current-path">
    <ol>
        <li class="icon btn-home"><a id="home"></a></li>
        <li><a>Folder 1</a></li>
        <li><a>Folder 2</a></li>
        <li><a>Folder 3</a></li>
        <li><a>Folder 5</a></li>
        <li><a>Folder 6</a></li>
    </ol>
   <input name="currentpath" type="hidden"/>
</div>

However, in the meantime, there is some points of discussion we can have, can you give me your opinion on these points:

1. Refractor tags to be more flexible : renaming css class, add some parents div in the base structure and only use ID on JS (maybe it's already the case) to be able to define in the wiki what is mandatory during a theme creation.
2. I saw you add some css/js dynamically at the plugin initialization. I think we can add all the js/css in the index.hml file.
3. For the base html skeleton, I think it's a good idea to put this on a theme.js file in the theme folder and appends the content of the file at the initialization. Like this, a theme could be able to change the disposition (to have very different themes).
4. The default file's icons (folder/file/extension without generated thumbnail) should be handled at the client level. The connector should not depend of the file manager structure/icon (and it's unnecessary the plugin can handle this easly with the extension)
5. Related to the point 4 : remove images files icons. I saw at the time when I wanted to create a file manager, an example where folder and file icons are full CSS. You can see the exemple here:. I think it's a lightweight solution and very flexible, you can if you want in the css of your theme use a file background (of your theme) if you want).
6. The move functionality is a little to complicated, I don't know what you think about that. The user should select a existing folder with a mini navigator (like the main navigator of the fm). I don't know if it's complicated to reuse this code.
7. Use class instead of inline style for the "list view" (like the tree), to be able to change easily icons and to be cleaner.

(your suggestions)

That's the last suggestions I had, be reassured !

[psolom]

Ok, I will wait for your fork to see the changes, and do not rush, I need 1-2 weeks to complete all the planned changes. With respect to the points in your list:

1. I would like to avoid ID and use classes prefixed with "fm-", you probably have noticed it. For my opinion it's more flexible and helps to avoid conflicts when the FM is included in a page among the other DOM elements. Also now it's possible to have 2 or more FM instances on one page, not tested though. is Can you do it with classes instead of IDs?

2. It was done to not load unnecessary assets. For example, if "edit" option is disabled in config file we don't need CodeMirror assets, which are numerous and heavy enough.

3. What content is supposed to be included in theme.js ? If it's just a html then which part of the base html skeleton it's goint to replace? The whole skeleton or some parts?

4. Yeah, I also have come to such conclusion. I will do it in the same way as it's implemented for filetree. Check filetree.css file. But, please, don't make any changes related to filetree (including html and css) I'm currently replacing it with another plugin which will allow to implement actions for batches of files/folders in the future. Nothing wrong if you have already done, this just may bring more difficulties while merge.

5. Hmm, As I metioned before it a good idea to use css for icons, but I haven't thought of such a radical way :) It looks progressive, but I'm not sure we have to completely reject the idea of image icons. But if will have it implemented like filetree.css I guess it will depend on theme. What do you think?

6. Don't worry of that. It will much easier to handle all actions after my next release. Filetree will be rewritten as I mentioned above and main view will utilize knockoutjs to make manipulation with files/folders easier. Knockoutjs have a great impact on html, but I believe we will be able to handle the migration :)

7. Yeah, it may be already changed after the impact of knockoutjs

I will keep you in touch, perhaps I will perform next release a bit sooner with some bugs, just for you to see all the changes and keep you changes consistent. Thank you for your efforts and great ideas.

[fabriceci]

I will wait your next big release to continue, no problem!

• I think the more flexible and simple solution (already work) is to use the file manager into a Iframe like TinyMCE.
• I wanted to say: use IDs only for JS and classes for CSS. Sometimes if you need to use classes for JS (or if you don't want to use IDs), the best thing to do I think is to separate classes for style and classes for JavaScript.

e.g. « fm-js-success-btn » (for js interaction) & « fm-btn fm-btn-success » (for style).

Like that, when you build a theme you know exactly what you can modify and what you shouldn’t touch.

• Normalize name of classes (maybe you already started that in the next release). Just add the fm- prefix like you said , and add a class when a div contain just a ID.

<button id="home" name="home" type="button" class="fm-btn fm-btn-home"></button>

• And a little extra :) , if you pass in this template during you work in your next release :) , add some css tag here, it's very hard to stylize for now:

    <div id="preview" class="fm-preview-container">
        <div class="fm-file-preview-container">
            // [ representation code here ]
        </div>
        <div class="fm-file-info-container">
             <div id="main-title" class="fm-file-title">
                   // [title here ]
            </div>
             <div class="fm-file-details>
                   // [ol here ]
             </div>
        </div>
   </div>

<div class="fm-toolbar-container">
    <form id="toolbar" class="fm-toolbar-form"></form>
</div>

2-3 ) The purpose of these points was to have only one line in the index.html file. Assets will be included by the plugin and the html skeleton by the theme.

For now, only the skeleton (I don’t know if there is an interest to have other parameters) will be in the theme.js/theme.config/theme.json file. If nothing is set, the default skeleton will be loaded, otherwise, the variable will contain the whole skeleton (lines 38 to 107 of the dev index.html file) to be able to change the position of all the fields.

4-5) If you use class : class="[base-class] fm-file-[ext] :

 <span class="fm-file-icon fm-file-js" />
 <span class="fm-file-icon fm-file-css" />
 <span class="fm-file-icon fm-file-folder" />
 <span class="fm-file-icon fm-file-folder empty" />

The theme could choose to use images or full css. And better again, each theme could have his own images.

6-7) OK :)

[psolom]

I agree with some of your points and some still make me doubt :) Could you post your Skype ID to continue the discussion on details there?

[fabriceci]

Yes for sure

[psolom]

@fabriceci I think this topic has exhausted itself and can be closed, isn't it?

[fabriceci]

I think the topic shouldn't be close, we have to do something about the design anyway!

[psolom]

According to this ticket I replaced almost all ids into classes (for CSS usage).

We had a discussion and came to the conclusion that it makes sense to make more severe changes after (along with) migration from Knockout.js to another framework. The implementation also will depend on what exact frontend framework will be used (especially templates side). Since it does not a matter of a few days, and suggestions in this ticket may change I suggest to close this issue and rise more concrete requirements when it will be clear who will take care of framework migration and what exact framework it will be. So that this ticket may confuse more than clarify at the current stage.

[fabriceci]

But to have a real performance boost, you need to rewrite all, so it will be a new project and that seems to be a bit unrealistic (needs a lot of works). What do you think?

The current version is mature, the only drawback, is the design (and more connectors)

[psolom]

New connectors implementation depends on maintainers and out of the scope of this issue.

I can agree with, but I'm not a designer and not good in making HTML layouts. This tickect is open more than one year and since neither you nor anybody else have been taking care of this so far I can conclude that nobody really interested in this. Let me know if you are going to implement new design and SASS/LESS files personally. Otherwise I will insist that this ticket makes no sense and should be closed.