Looking for feedback

[JCDinPGH]

No preference on removing tabs.
New config-"paper" option sounds interesting!
No preference on browser.
No preference on .NET framework version.
No preference on scripting language (will have to learn both) but would love as a feature!
Would rather have new features added first.
Given the recent development cycle, I'd prefer small frequent updates.

Just so I am clear, I absolutely love this software and use it every single day. I'd really like to see it developed more actively although I understand it's a hobby.

[chemelli]

Hi all,

I'm a quite new user but I would like to highlight the only issue I found when comparing to Microsoft RDC manager: screen resolution handling.

Would be possible to have a new option "same as client area" so that I can easily switch from pannel->full screen->pannel without loosing desktop area ?

Thank you in advance,

Simone

[manuc]

Tabs within tabs: I really like this feature and would prefer you don't get rid of it. Why not just make it so that if there is only one panel used it doesn't show up. That way people who don't use panels can keep everything on the default and don't get the clutter.

Config pane: I like my configurations panel, but I'd really, really like a shortcut key to turn it on/off. Likewise for the connections panel. I connect to everything through the quick-connect button, but if I want to start an external app I have to turn it on in the menu, select the host, start my app, and then turn it off again. If I could just press F6 to quickly open it that would make me loads more productive -- as most of my work is done in mRemoteNG. (I even integrate onenote into it to keep my documentation together)

[btrower]

Re: Any problems with removing the tabs within tabs? I would like to keep only the top/outer set of tabs.

As others have stated, the functionality is important. However, the placement of these things eats up a lot of screen real-estate. The interface should allow us to get the full height of the screen less borders, a menu and (perhaps) one small ribbon. It would be nice to be able to specify most placements so that, for instance, we could set up (say) a 600 px wide band at the side to act as a control center and give the windows on to the right of that the entire height of the screen. I have three monitors side-by side here and am about to add another two for five monitors across. Those tabs and ribbons at the top consume an unacceptable amount of real-estate. When there is only one tab at a given level, the 'sub-tab' level should not be there.

Re: Any problems with removing the config pane and replacing it with a configuration dialog? Two ideas: ...

Yes. Don't do that. Right now you have something that already makes sense. If you change it, at the very least, give users an option to go back to the current setup.

Re: Any reasons to keep the Gecko browser support if we greatly improve the IE support?

Not sure I get what you are asking, but it is better if you can use IE PLUS at least another one. The Wunderkind at Microsoft appear to have a broken IE 10 in Windows 8, for instance. I use Chrome, IE, FireFox or Opera fairly routinely trying to find a browser that will work for a given website.

Re: Any problems with increasing the required .NET Framework version from 2.0 to 4.0?

That is probably not a big deal. It would run out of the box on this current workstation. Dependence upon .NET is a big deal. Once you are there, demanding a higher version should not be as obnoxious as requiring it in the first place. I have *six* versions (4.0 included) on this machine and it is just my 'window' on to the systems where I actually work. Chances are, if you have not demanded it, some other application will.

Re: If scripting support were added, would you prefer Python or Ruby? If neither of those, do you know of something else out there with a well supported .NET interface?

If it were up to me, I would prefer to see all the code tightened up, bugs fixed and usability issues all ironed out *before* embarking on a decision like this. I have yet to meet a scripting language I did not pretty much hate. I cannot help but think that if there were a modern language actually written by a team of programmers (real ones who have been heads-down programming for more than twenty years), the entire distinction between compiled code, bytecode or interpreted code would disappear. </rant>

Re: Any ideas how we can get more developers to help improve mRemoteNG?

Yes: make the code easy to compile, to hack, to 'brand', to port, etc. Break out tasks that can be done in a couple of hours and reduce the 'setup curve' so that an experienced programmer can download the code, satisfy himself that it compiles *as is* and get to the place where the code needs to be done and do it. Nearly every single open source project I ever download does not even compile, let alone run, as packaged. Stuff should be vanilla, vanilla, vanilla. Note: I have not downloaded the code for this latest incarnation, so it may be pretty good. The last time that I had this code, it did, at least, actually compile and the compiled code did actually work. However, it was, at that time, very fragile so that even trivial changes would break it. There are, I suspect, literally thousands of excellent programmers that could and would come to work on a project like this if they could get in, get a job done and get back out in time to do their day jobs and take care of their families. I am stopping to write this because I am pleased that somebody has taken this on and because I am hoping to come back to this code and package it up for sale to clients. However, like most people with this type of skill, I am terribly pressed for time. I have stuff to deliver *tomorrow* and even stopping to write this note comes out of my sleep(!).

Re: Any ideas how we can get more people to help mRemoteNG in other ways: documentation, website design, bug triaging, translation, etc?

Absolutely. Similar to the above, make it easy. Break out work into *tiny*, *tiny*, *tiny* bits so people can get in, get the job done and get back out again without making this into a primary commitment. This is a terrific body of code that does something *very* useful. If people could easily join the team, break off a (did I mention microscopically small?) bit of work, do it and get their name up in lights, they would be all over it.

Re: With our very limited development resources, where would you rather we focused our time: fixing bugs in current features or adding new features?

Absolutely, without any doubt or equivocation, make this code *squeaky* clean before you contemplate new features. You will find that as you re-factor to make it verifiable, trim redundancies, and review the same code (especially with 'new eyes') that excellent opportunities to make meaningful and lasting contributions will present themselves.

Re: Do you prefer small, frequent updates, or larger, less frequent updates?

As a developer on the hook for delivering things, I prefer to take my time. However, as a practical matter, frequent updates are mandatory to ensure that things stay on track. If people do not see bug fix updates (when bugs are known), they may start to take their attention elsewhere.

Re: Any other ideas on how we can continue improving mRemoteNG?

Coding like this is a social exercise as much as a technical one. Your reaching out in this note has elicited a very expensive response from someone like me because you asked nicely and your points were specific and actionable. That was/is a good thing. You could expand upon that by reviewing what you feel needs to be done, breaking it into manageable chunks and heading out into the programming bulletin boards and soliciting answers from people. Make it easy and rewarding for them to join in back here.

As someone who spends all day at the keyboard doing technical stuff (like software development, but other stuff too). It grieves me how relentlessly crappy all the software is. I just tested the Windows 8 Metro interface last night and it was gruesome. They may make a success of it yet, but Explorer 10 crashed on me literally within a minute or two and given how irritating Metro is on an initial meeting, it does not give me confidence. If they can't get it right with billions of dollars, thousands of people and a captive customer base, we can be forgiven the odd glitch in our work, no?

The software, as things like this go, is excellent really. It can be improved by many little refinements such as behaving sensibly when tabbing through the config pane, having context sensitive help, context menus, etc. Little things such as the fact that when I press F1 for help it keeps opening a new identical help tab make it look not quite finished.

There is a dependency mentioned in the 'About' page on 'DotNetMagic' which, when I click through to their website, tells me that the product has been discontinued. If we have the code and are able to, we should fork the open source project. If it was closed source, well, this speaks eloquently to the advantages of open source ... Whatever depends upon that stuff should be found and the dependencies replaced with something that can be supported. That is something of a 'To Do' that someone familiar with the code might be able to stub out and have others help to either code around or find open source equivalents.

----------

I hope that does not seem critical. You have done good work here and the original body of code was very much superior to the majority of software open or closed.

I expect to be using mRemoteNG more often in the next month or two. As I go along, if I discover something that I think should go in the 'job jar', I will let somebody know and if the 'job' is small enough, I will do it and pass it back to you.

Cheers!

[joedissmeyer]

Any problems with removing the tabs within tabs? I would like to keep only the top/outer set of tabs.
I agree that removing the tabs within tabs should be removed. When I was showing several of my colleagues the UI for MRemoteNG, they were confused on why the tabs within tabs was there. Also, I don't use this feature.

Any problems with removing the config pane and replacing it with a configuration dialog? Two ideas:
--Place the config "on the back" of the remote session and have it "flip over" to show the config. So, a piece of a paper metaphor, with one side being the config and the other side the terminal or remote desktop.
--A separate dialog (like the new options dialog)
I actually currently like how the config pane exists. However, if you were to change anything I am more interested in seeing how the paper metaphor would look like. I don't like the idea of a seperate config dialog box.

Any reasons to keep the Gecko browser support if we greatly improve the IE support?
My browser of choice is Google Chrome. However, I am open to keeping Gecko because it seems as if Firefox has better compatibility when compared to IE9/10 and Chrome. But I will say that IE10 in Windows 8 is much, much better than IE 8 or 9 ever was.

Any problems with increasing the required .NET Framework version from 2.0 to 4.0?
I have no objections to moving to .NET 4.0, or even .NET 4.5.

If scripting support were added, would you prefer Python or Ruby? If neither of those, do you know of something else out there with a well supported .NET interface?
Windows Powershell or VBScript are the scripting languages that I personally use. But I'm not sure if that is what you are looking for....

Any ideas how we can get more developers to help improve mRemoteNG?
I would be happy to contribute. However, I am a coding novice and would be more of a burden. Also, I don't know many freelance coders. But I would be a good beta tester or UI designer.

Any ideas how we can get more people to help mRemoteNG in other ways: documentation, website design, bug triaging, translation, etc?
I would be happy to contribute in creating documentation for MRemoteNG. I have already started working on documenting several "how-tos".

With our very limited development resources, where would you rather we focused our time: fixing bugs in current features or adding new features?
I vote for quality over quantity. It is always nice to have new features, but making sure the product runs flawless should always be the main goal. Case in point - initial releases of Apple's iOS5 and iOS6 updates.

Do you prefer small, frequent updates, or larger, less frequent updates?
I personally prefer frequent updates maybe once per month or depending on what bugs are fixed, and\or if new features have been added.

Any other ideas on how we can continue improving mRemoteNG?
- Improve SQL Server support. Basically remove from experimental support to fully supported.
- Have a SQL Server database setup wizard? Not sure if this can be done or not.
- Ability to change the app window themes\colors.
- Possibly move from the Office 2003 style window to Office 2010 style Ribbon UI? I'm not sure how well it would accompany MRemoteNG. But, I do think that it would help make the app appear more professional and modern. Also, if moving to the Ribbon UI, that may solve your question on moving the Config pane (you could possibly move all, or most, of the configuration settings to the Ribbon).
- SSH File Transfer needs to be better. It would be great to have a commander style SCP\SFTP browser with drag and drop support. This would remove the need for many to rely on using FileZilla, or WinSCP, or other FTP apps since it would be embedded inside MRemoteNG.
- Port MRemoteNG to Windows 8 (Win8 app) and sell it in the Windows Store! I would definitely purchase MRemoteNG.

[genup1234]

fixing bug,
bigger and less frequent

i would like it when i copy the config to another users profile on the same computer it remembers the external tools. at the moment i have to remap the tools each time i copy it.

i like jrapps concept of dockable panels in a grouped tab

other than that its great

[q2956]

Hi,

I would like to suggest three features that I miss quite much:

1: a minimal mode in regards of the control elements would be great. You are usually working 99% of the time in the session it self. So you need mremoteNG to establish the session, but most of the elements like menu bar (File, view, tools and extras), the General tab, notifications, sessions are not necessarily needed.
It would be great to be able to remove or disable these elements for a bigger session window. Especially for Notebooks and devices with a lower resolution.

2: It would be great, to be able to start a Session like SSH or RDP in a separate new window. This would be on multi monitor screens a great thing. Or it would be to undock the session tab from the panel tab into a new window.

3: Panels (like General) and the positioning: It is now possible to move the panel (General) to an other screen, but you must fit the panel window manually. The minimize and maximize control elements are missing and there is no possible way to define which panel should be opened on which screen.

Greengs, q

[dedekmraz]