Extremely poor or strange appearance

Hi,
Not sure if this is a case for a support or bug forum. I cannot believe this is the way it is for everybody, so I’ll make it a support post:
I’m using Komodo IDE 10.1 with - Interface color classic, widget colors Tomorrow_Light, Editor Colors Classic.
My choice is dictated by the fact, that I want to write and read on white pages (as opposed to black terminal windows)

What disturbs me a lot is that differently from Komodo 9:

  1. all tabs and input fields lack padding
  2. Folders are only marked by a > and not a folder icon
  3. I have chosen not to customize colors, because experience tells me that when I’m finished you will deploy a new version, so I chose basic themes with no changes, but some things are just not usable:
    • text that is highlighted in e.g. “find in files” is rendered gray on a dark blue background and the text is simply not visible (other places in the UI where the text is highlighted with dark blue the UI chooses to render the text white, which is visible and readable)
    • when I highlight a variable which is inside brackets, the variable is highlighted in light gray and the brackets too, this makes it impossible to tell whether the highlighted text is only the variable or the variable plus the brackets, or one of them (hence who knows what happens if I Ctrl-x?)

Finally, when I close a project, files opened in that project do not close, even if I have chosen:
when opening a project: Open recent files
when closing a project: Close all open files in project

Thanks for any help

I don’t know what you mean here.

Yes, folder icons were removed.

The UI customization backend was in some flux for a while and we do apologize for that but huge changes went in to make it a lot easier. Customizing the UI is recommended and easier than ever now. You can even add custom CSS if you want to get really technical.

I can’t reproduce this. I have the same setting and it’s working as expected. Are you sure those files are with the root directory of the project?

  • Carey

Padding in inputs and tabs is really small. However:

:slight_smile:

Pls. see a screenshot for komodo 9 (with right and left padding)

and komodo 10 (with no right and left padding)

also icons in 10 are smaller and the result is a cluttered tab line, it’s very unpleasant to try and find a tab there. It’s also more difficult to hit the x when you need to close a tab.

Also somewhat related: opening a file in a new project:
Komodo 9:

Komodo10:

In the beginning I thought something was broken, see the wide space between the button and the corresponding menu? It looks like the menu relates to the “open project” button, which is located beneath the “open file” one.

You have probably some reason for this, but seen from my point of view as a user, I really don’t get it: a folder is a folder; you have folder icons elsewhere in the GUI, why not using it every time there is a folder. Why should I use energy to:

  1. get used to a different icon for the same thing going from IDE version 9 to version 10.
  2. Get used to discern when a folder is hidden behind a folder icon and when it is hidden behind a > icon.
    I don’t see the problem that you are trying to solve for me in return for the inconveniences that you are imposing to me.
    It’s just: if it ain’t broken, don’t fix it.

I’m uploading a screenshot for that:

Is it possible to force the text being white when it is highlighted? That would solve it.

Maybe you have misunderstood me on this point. I have chosen a “classic” interface and have not customized it on purpose, because, next time you come up with a new major version I will probably have to do it all over again.
I did customization with version 9, triggered by the fact that you had made the location pane brighter than the code pane: when I first saw it, I thought my sight was suddenly become bad, realized then that the culprit was the grayish background of the code pane, and the contrast to the brighter location column. So i started finding colors that were good enough for me (looked like those I had in version 8), when I was (almost) satisfied, the version 10 came about, and I had to start all over again. Now I would prefer not having to customize however nice the result might become. A decent starting point should be a reasonable requirement, at least texts should be readable and somewhat standard padding too.

The idea that I can customize the css to my liking is cool enough, but please do not use it as an excuse not to provide good enough interface. When I make website for my clients I use libraries so that I don’t need to think about a decent starting point, the lesser I want to spend my time tinkering the css of a tool that I have payed for just to be able to read a text.

OK, I got this: until now I’ve always worked with “remote folders” residing on a different box than my PC. So the project definition files were saved in one folder on my local machine, one single folder keeping subfolders, one for each of the different projects. The “close files when closing project” feature worked in that case, even if the (remote) files had no relation to the location of the project definition file. Now I’m working on a project whose working files are kept inside my PC and I still keep the project definition file in the same folder where I have all my other project definition files. This is of course unrelated to this particular project. I didn’t know it was a constraint to make this work.
Apparently when working on remote folders the constraint does not apply.

Could it be a feature request that a project does not need to be placed in a subfolder of where the project file is saved?

Thanks for repeating exactly what he said @Defman :wink: Very helpful. I meant that I can’t picture the issue. I don’t see any problem with padding.

  • Carey

I don’t either :slight_smile: But he gave a screenshot and the padding is broken. Mine paddings looks normal for me.

Thank you for the screenshot. I now see what you’re talking about and no it’s not supposed to look like that. I can reproduce this in Classic mode. It looks fine in the default skin. You can file a bug for this issue if you like: Sign in to GitHub · GitHub[quote=“tribis, post:1, topic:3114”]
Folders are only marked by a > and not a folder icon
[/quote]

A large goal for Komodo 10 was to de-clutter the UI. I didn’t make this particular design decision but I believe that is the reason behind it. I don’t understand the inconvenience you perceive with this change. Nothing has changed other than one indicator out of two has been removed. There was always a > in this UI to indicate the folder was open or closed. Why would we have two?

I do understand your point and it’s very relevant. But I don’t think you understood my response. The UI customization has become much more stable so you should be able to trust customization more. Having said that, if you don’t want to customize (I don’t, I hate customizing UI) then please do file bugs for things that you think are wrong or could be better.

This isn’t a fair statement at all. This isn’t remotely how we work. We provided the this tooling as an extended benefit to our users, not as a cop-out. If there are bugs then please report them and we will fix them.

Thanks for clarifying. Assuming you “added” the local folders to your project (Right click project > Add > Existing Folder) then this would be a bug. I just tested it and I get the same result as you. Komodo should close any files that are located in those added folders.

@Defman, these comments aren’t very helpful. Please let the original poster answer questions about their post.

  • Carey

I’m glad to hear that many of the things I reported are not supposed to be the way they are. I will file bug reports for them. Thank you for taking the time to verify them.

I’m still convinced that removing the folder as a decluttering strategy is an error: there is nothing more powerful in giving you the perception of what a spot is and how to use it like a folder icon, it is universal in computing. You can discuss if it is required to have an extra clue for open and close (the >), but then you could have chosen to have a close and open folder that would only take the place of one icon (and let the user customize if they want to click open in single or double click). The > requires me just a millisecond thought of “ah, yes that’s the folder”, of course it will stop at some point, like stopping to smell smoke when being close to smokers. Only, when I see the folder icon on the project pane, it just remembers me of how good it felt to have it everywhere where a folder really is.
This might sound like a sentimental approach, however it is nothing else than pure logic: in general it is deemed that icons vs arbitrary signs, help usability. This is because they make pictures real in your mind, hence they speed up perception.
Then if this is true, you should use icons wherever it is possible and sensible.
If this were not true you should use arbitrary signs everywhere. No clutter at all.
A third possibility of course is that exactly the folder icon should for some reason be overrated and really not useful. This seems to be the rationale behind your (Komodo teams’s) choice. Given the ubiquity of the folder icon I find difficult to defend this idea.
And, more on the practical side, having a nice “real” yellow folder in the projects pane while having cold abstract clues on the file system pane, makes me automatically focus on the project pane, it’s just bad luck that I (as everybody) use the filesystem pane 100 times more often than the project pane.
I hope you take this as a frank and honest attempt to clearly explain why you should change this decision.

I apologise for the harsh statement reg. coolness of css, I acknowledge 100% what you say.

Now that I know how things are I’ll file bugs for what are bugs. But I hope you’ll send my comments about folder icons to someone in charge of it.

Thank you , Paolo

Sorry missed one:

Tools > Color Scheme Editor, on the right hand side select Interface from the dropdown, find Toolbar (this is a bug).

  • Carey

Ah, yes, that did it. Thank you!

I’m saying this way too often :frowning: but this is a bug. That’s an artifact from the old UI that didn’t get updated. That icon shouldn’t be there.

DEFINITELY. Always. We’re writing Komodo for you (and other people I hear) so your feedback is key. To clarify, de-clutter doesn’t mean remove all icons as you indicate our thinking might be. It was more remove Icons that don’t make sense or that just don’t need to be there. You make a good argument for keeping the open/close folder icon and removing the >/v symbols.

I’ve filed an enhancement request. Note the possible caveat in last paragraph of the report: Replace `>/v` symbols with folder open/close icons in Trees · Issue #2042 · Komodo/KomodoEdit · GitHub

  • Carey

Filed: Old folder icons are still included for a Projects added folders · Issue #2043 · Komodo/KomodoEdit · GitHub

  • Carey

thanks again, that makes it definitely worth taking the time to report.