Initial run of Komodo Edit 9 rc1

I thought I would give the 9rc1 an initial look this afternoon, and installed Komodo Edit on one of my Macs where I do not have Komodo IDE installed, although I do have Komodo Edit 8.5 installed. I’ve attached a screenshot from the initial start-up. Several items to note:

  1. The blank bar across the top with the “Sure thing!” and “I’d rather not” buttons at the right end of that bar. Any idea what that is supposed to be?

  2. It appears to have attempted to re-open a set of files I had open the most recent time I ran 8.5. Note that what appears to be the tab with focus (file “my-nps-index.cfm”) is completely blank. Selecting one of the other tabs shows the expected content and then switching back to that initial tab shows the expected content for the first file, so it appears the “blank tab on start” bug may still be lurking.

  3. The scroll bars seem oversized. Note how thick the horizontal scroll bar at the bottom is. It is also noticeably thicker than the vertical scroll bar, which is also way thicker than it needs to be and than any other application I’ve seen on this platform.

In screenshot 2:

  1. I’ve scrolled the file way out to the right, but the horizontal scrollbar appears to be completely disconnected from the content and from the scrolling.

  2. Note the different icons for the files in the “Open Files” panel on the right and for those same files on the corresponding tabs. Should those not be the same icons?

In screenshot 3:
6. Note the different icons for the same filetype in the tabs vs in the language selector available from the status bar. Should those also not be the same?

I will continue exploring.


/ron


1 Like

Are you seeing a problem w/ the prefs window where Color Scheme reports:

XML Parsing Error: undefined entity
Location: chrome://komodo/content/pref/pref-alllangfonts.xul
(etcetcetc)

I have this on 2 machines with both IDE and Edit even after nuking my profile.

The contrast between the gray icons and the bright-ish blue selection bar in the Preferences dialog renders the icons close to invisible. If the icons were to change to white, in the same manner the preferences section text does, for the currently selected preferences section (e.g., “Web & Browser” in the screenshot), they would be much more visible and the effect would remain consistent with the change being made to the text there.

Switching to “Color Scheme” entry on the Preferences dialog generates this:

1 Like

@neurobashing: Yes, same thing here. I’ve included a screenshot above.

The entity will be fixed in the next update (tonight/tomorrow).

1. Sure thing button

That controls the optional (opt-in) share usage metrics with ActiveState. I’ll leave to @nathanr to check on the styling details (it’s always been visible for me).

2. blank file contents

Yes, this bug still exists (I’ve fixed some of these, but this startup editor one still persists), I’ll be working more on it this week.

3. Scroll bar oversized

Another one for @nathanr, but I do agree. Same for the rest of the items.

I’m not even using Yosemite but I interesting in how works Yosemite built-in color picker in Komodo? It crashed Komodo few months ago so is it fixed or not?

Also @rstewart I see that the tab width (I mean “Open Files” tabs) automatically adjusted to the width of the editor window… So @nathanr is it a Mac-only feature?

Seems updating our OSX SDK screwed up the skinning of this panel, will fix. (It’s asking if you want to share anonymous statistics about your use of Komodo).

Known bug, will be fixed prior to release.

Also known, will fix.

This is new, will have to see if I can reproduce. Might contact you otherwise. Thanks!

Ehh not sure what’s going on here, your left pane icons should not be native OS ones. What iconset are you using?

The left pane icons are based on the file extension, the bottom statusbar icons are based on the language. Since you can have multiple extensions per language and a lot of these icons are “generated” we end up with odd use-cases like this. I’ll probably look into this prior to the final release but it’s not a huge bug in my mind. You can work around it by prioritizing your preferred extension under your file association settings.

Have not seen this before, will look into it.

Good point, will see if this is worth fixing prior to final.

I think this has already been fixed but will verify.

Should be. Can we not start reporting old bugs that arent affecting you? :stuck_out_tongue:

Not sure what you mean by this.

1 Like

I meant that.

As you wish :smile:

Yes it’s specific to OSX, as this is how tabs appear to be handled by native OSX apps.

Ahh, it’s look so cool… I’ll try to do the same styling in elementaryOS and Komodo.

@nathanr: Thanks for the follow-up.

RE Iconset: Preferences > Appearance shows “IcoMoon – Yosemite” as the selected icon set. Not sure if it matters within this context, but this particular system is running build 15605 on OS X 10.9.5 (I probably should have mentioned it in my origina post).

RE icons and file extensions: Can you elaborate on your “work around it by prioritizing your preferred extension under your file association settings” comment? The file extension of these files (.cfm) is the only file extension registered for that particular file type entry (CFML) in this install of Komodo. I typically manually register at least one additional extension (as I haven’t found a way to do that within the editor extension itself), but in this case there is just one in place.

RE the horizontal scrollbar: I’d be glad to provide anything I can to help track stuff like this down; just let me know what you need.

A few more items

  1. The “Find Previous” button on both the “Find” dialog is slightly taller than all of the other buttons in that area of the dialog.
  2. The “pin” button on the Find dialog could benefit from a bit of padding on the right and bottom of that button so that it isn’t smashed up against the edge and bottom of the dialog.
  3. The paths, etc., listed in the drop-down at the top of the “Places” panel have all been converted to uppercase, despite being shown with the correct case in the tooltip that appears if I hover over the “KOMODO-GOO” entry shown in the screenshot when that drop-down is closed.
  4. “Find” seems partially broken. So far, I have been unable to get “Find” when invoked by right-clicking on one of the folders within the project and selecting “Find” or “Replace” to find anything. If I use shift-Apple-F (which should be the same, I think?), and point it at the same folder, it works as expected.
  5. Has the handling of the minimap changed? It seems to now be file-specific rather global (e.g., if I toggle it on, it appears only for the editor tab which had the focus when I made that switch rather than being for all editor tabs and continuing to remain open as I open and close additional files). As someone who almost always has the minimap open, I really don’t want to have to always open the minimap the first time I open every file.

I will keep exploring, but will install build 15607 before doing much more poking.

In spite of these things I am finding, I have to say that I am impressed by how much you and your team have done in getting this version closer to release since the previous pre-releases. Lots of great additions since v8.5 and lots of polish being added.


/ron


1 Like

Very much appreciate all these reports, but as they do seem to be piling up please consider splitting them into separate bug reports. Having them in bug reports will really help us focus them down.

Regardless, will look into them as time allows.

@nathanr I will file the first four from my most recent entry in this thread above as bug reports, as those seem fairly clearly to be bugs.

Is the fifth entry (the handling of the minimap) a bug or has the handling of whether the minimap is open/closed changed from something global to something file-specific? If that is not the intended behavior, I’d be glad to file a bug report for that, as well.

Unless I have specific questions about things I find from this point forward, I will skip raising them here and just go straight into the bug system.

The minimap functionality hasnt changed. I suspect you are switching the minimap via the View menu, this toggles (and saves) it for the current file. When you change it via the pref screen it toggles it at the global pref level, though individual files can still override this.

I intend to simplify the global/project/file level pref UX but have unfortunately not had the time to do it for 9.0.

@nathanr I’m still hoping you will elaborate on the above. I’ve logged bugs for all of the other items I’ve raised in this thread that you or @toddw did not indicate were known items.

RE the minimap: Turning it on via the preferences setting yields the expected global behavior. I probably just forgot that’s how I had turned it on in the past.

This is theoretical but if you go to Prefs > File Associations and delete all patterns for the language whose icon you want to change, then add them in again but “start” with the one whose extension you want to appear in the icon.

You will have to delete <profile>XRE/icons and restart Komodo afterwards.

Ugly workaround, I wouldnt suggest it unless you’re REALLY bothered by it.

@nathanr As I noted, I have just one file pattern (*.cfm) registered for this language type (CFML), and it is the pattern registered by the editor extension itself and not one I manually added. In this install of Komodo Edit, it is the only file pattern that has ever been registered for this language, so I’m not sure where the “TXT” icon is coming from in the language choice list available from the status bar. The differences in the color and in the labeling are the parts there that feel inconsistent to me. (I hesitate to use the word “wrong”, as there is probably lots more at play here than I will ever know, but it does not make sense to me.)

I would expect the icon in the language type selector to be based on the file extension specified in the editor extension, since that is where the “CFML” entry in that list comes from, and I would expect the coloring of that icon to match the coloring applied to the icons used in the Places panel and the editor tabs for all registered file associations.

Early tomorrow, I will give your workaround a try, and let you know if it works.

Thanks again for your help.

Updated: Followed the above instructions, and then removed what I believe to be the write folder (~/Library/Application Support/KomodoEdit/9.0/XRE/icons). Restarted Komodo. The …/icons folder was recreated on startup, with what appears to be the same result (gray TXT icon in the language selector for the CFML language). The good news is it is consistent; the bad news is the logic used to generate the icons for the language selector does not appear to be based on the file association?

Has this Icon issue been reported as a bug yet? Trouble shooting should really be taking place there. It sounds like we need to follow up on why the logic is failing in the status bar.

I saw most of your bugs @rstewart but can’t recall an icon one. Would probably help for future users to include the bugs report in this thread.

  • Carey

Bug: https://bugs.activestate.com/show_bug.cgi?id=106311

Does sound like something is messed up there that doesnt cover the use-case I described in my workaround. I’ve updated the priority accordingly.