The reason why we’re asking these questions is the following: we’ve encountered some situations then RMI was misbehaving if localhost resolving is somewhat broken, e.g. issues like that - http://stackoverflow.com/questions/11343132/rmi-responding-very-slow. We believe that we eliminated all known reasons for that, but your case could be a new unknown problem.

[offtopic] here shown installation wizard, but I was able to find Android SDK only in ZIP distribution. And there is a command-line SDK manager, no GUI. https://www.jetbrains.com/help/idea/2016.3/prerequisites-for-android-development.html

I’ve uninstalled Android Studio and trying to go back to work with IDEA EAP, so I have no working AS for now.

nslookup localhost
Server:		192.168.1.1
Address:	192.168.1.1#53

** server can't find localhost: NXDOMAIN

@User uploaded a file: ifconfig

We’re probably not using VPN, but I don’t exactly know simple smile

If you’ll resolve

** server can't find localhost: NXDOMAIN

- your problems quite likely will be gone. But I’m quite curious why RMI still have problems with that.

It could usually be solved by editing

/etc/resolv.conf

@alexey.sedunov ^^

Okay, I’ve set Yandex DNS 77.88.8.8, and this warning gone. I have also some HDD problems, they may be the cause of freezing everything including system UI.

@User uploaded a file: and commented: This is a very minor issue, but why do some files show up as classes (FileWatcher and OrderedViewSet above), and some show up as files (Store.kt)? In all three cases the class name in the files is the same as the filename

you have some top level functions alongside the class

would be nice if there were another way to see that "this file contains a class and other top-level functions or extensions to it"

I agree, but we couldn’t find a non-conflicting way to do it yet

Add some Java files in the same folder… add some text files… and it becomes a complete mess

A file <Name> with class <Name> and some other stuff can be displayed as a file with a circle (class) on top of it. 🙂

Yeah, I feel the same way. Differentiating "pure" class files from class files with other stuff is definitely important, but I also want to be able to easily differentiate files that contain only functions from files that contain mainly a class with a few accompanying functions. Actually, I would even say that the second case is probably a bit more important than the first one for me personally.

it's not just a matter of the icon. when a file contains a single class, the project view node is the class. any actions you invoke on the node from the project view affect the class, not the file

when a file contains more than one element, no matter what elements are there, the node has to represent the file

we can change the icon, of course, but it still won't have the visibility marker, for example

Ah, interesting point, didn't think about that. Fair enough, at least for me the missing visibility marker wouldn't be much of a problem, but having an icon that communicates "This is a file with a class in it that has the same name as the file, plus some other stuff" would be really nice.

I personally think that this wouldn't be noticeable enough to make a difference

For me, it would. For example I'm scanning a package for a file that only contains extension functions, but I don't know it's name anymore - first thing I look at is the icons. All icons that represent a class are out, but if there are files with a class and some other stuff they look exactly the same, though semantically the play a very different role in the package, and now I need to scan their names, too. It's just a minor inconvenience, but it would definitely be appreciated 🙂

Or, if I want to quickly get an overview of all major classes in a package - having to manually look at the "file"-icons to see which of those actually represent a class semantically slows that down quite a bit.

I am using kotlin 1.1.1; maybe it is a 1.1.1 plugin issue

what do you mean by "doesn't work"? what happens when you select that option?

@yole it does not switch to the new window

if the window opens but remains in background, then it has absolutely nothing to do with Kotlin. Kotlin doesn't control which IDEA windows are activated when

Yup, definitely not a kotlin issue, I have this happening in different kinds of projects.

ok, maybe it is a IDEA issue