View Full Version: NStudio 0.1-alpha6 (0006)

nrpg >>NStudio >>NStudio 0.1-alpha6 (0006)


<< Prev | Next >>

NRPG- 05-27-2007
NStudio 0.1-alpha6 (0006)
---=== 0.1-alpha6 (0006) (27-05-2007) ===--- - Feature: Added multi-language GUI system (English language is default) - Feature: Added new type of text editor(light and fast): Windows Standart Text Editor (like Notepad) - Added: Added Bulgarian language - Added: File menu improved (added closing functions) - Updated: ICSharpCode.TextEditor updated to version 2.1.0.2526 - Updated: Math Tools v0.2 (added expressions evaluator) - Fixed: Options dialog is no more showing in task bar - Fixed: Few GUI bugs fixed Download: http://nstudio.hit.bg/NStudio-0.1.A6.rar

The MAZZTer- 05-28-2007

Interesting tool, it shows some good promise! However I have a few suggestions: - Using icons can improve an interface, but there is such a thing as too many icons. The icons on the top level menus (File, Edit, etc) conflict with the standard "text-only" style used by every other Windows program. IMO you should consider removing those icons. - Have all plugins loaded by default and automatically (scan the plugins folder for DLL files and try to load them). You can use an options dialog tab with a CheckListBox to allow the user to disable/enable plugins. - It is possible to load the same plugin multiple times. This should not be possible, IMO. - I do not see a way to reopen a FileSearch tab without reloading the plugin. You should be able to open as many FileSearch tabs as you want with one plugin. - Your plugins' menu "Loaded Plugins" option has suboptions which do not do anything. I recommend you move this into an options dialog as I described above, or make sure every plugin has a submenu under Plug-ins like FileSearch does. - In addition, the FileSearch menu cascades into more menus... IMO you should try and consolidate them into one menu. If you want to use top level menus, it should be on the top level (perhaps allowing plugins to add items to top level menus could be another alternative, but this would be messy). Another solution is to allow plugins to add a tab to the options dialog, where plugin settings can be modified. Also you can put buttons on the main FileSearch UI to replace some of the menu options. - The Mozilla Firefox Plugin is a dead link. Please mirror it somewhere else, I like Firefox! :) - The browser tab has it's own statusbar, which doesn't look good if the other statusbar is there too. In addition, it has a gripper in the lower right corner (usually for resizing a window) but it is unusable. When in tab mode, the browser should not have a gripper in its' status bar. - You have two ways of changing the Renderer. Through the View menu or the View toolbar. But if you use one to change, the other one stays selected on the old Renderer! I have done similar UI things and I recommend making a function handle the MenuOpening event for both, to determine which renderer is being used and then to checkmark the appropriate menu option. There are other ways of fixing it but I find this way works best for me. - When using File > Open, the menu stays open while you are using the dialog. This doesn't fit with traditional Windows open dialogs (the menu closes before the dialog appears) and the menu can also sometimes obscure the dialog. - Typo... "Standart Editor" In both File > New and File > Open. I think you mean "Standard". - The "Close" and "Save As" options are not disabled when there are no documents open. - When opening a file, you should be able to determine which editor to use based on the file extension, the user should not have to explicitly select one. In cases where you might want to override the extension, the user should be able to explicitly select one, but there should be a general purpose Open dialog which can autoselect an editor to use (Visual Studio handles this good by making the Open button in the dialog a dropdown button which allows you to pick another editor directly from the Open dialog, but you may find it not worth the effort to do all the dirty work needed to change the dialog). This is a very interesting project, I look forward to seeing more plugins and useful developer tools built-in (sidebars are fun!) and I hope my suggestions help! :)

NRPG- 05-29-2007

Great suggestions. Thanks! I will fix some of them in alpha7 :) If you have other ideas or know bugs you can tell me at any time! Thanks again!!!

RMPG- 05-29-2007

Yepp nice post, we will improve the program in every new version you will see more and more thing that work correctly!

NRPG- 05-29-2007

- Using icons can improve an interface, but there is such a thing as too many icons. The icons on the top level menus (File, Edit, etc) conflict with the standard "text-only" style used by every other Windows program. IMO you should consider removing those icons. I thing its better to have icons in the top level menus. Its better for user to find what he need. - Have all plugins loaded by default and automatically (scan the plugins folder for DLL files and try to load them). You can use an options dialog tab with a CheckListBox to allow the user to disable/enable plugins. I added ability to load all available plugins in the plugins folder. - It is possible to load the same plugin multiple times. This should not be possible, IMO. Fixed! - I do not see a way to reopen a FileSearch tab without reloading the plugin. You should be able to open as many FileSearch tabs as you want with one plugin. Done! - Your plugins' menu "Loaded Plugins" option has suboptions which do not do anything. I recommend you move this into an options dialog as I described above, or make sure every plugin has a submenu under Plug-ins like FileSearch does. I thing to add unload ability there, but can't do this now. So for now I will not do anything there. - In addition, the FileSearch menu cascades into more menus... IMO you should try and consolidate them into one menu. If you want to use top level menus, it should be on the top level (perhaps allowing plugins to add items to top level menus could be another alternative, but this would be messy). Another solution is to allow plugins to add a tab to the options dialog, where plugin settings can be modified. Also you can put buttons on the main FileSearch UI to replace some of the menu options. FileSearch Plugin menu is now on the top level. - The Mozilla Firefox Plugin is a dead link. Please mirror it somewhere else, I like Firefox! :) This is really good to see IE and FireFox in one program. Isn't it? :) Try this: http://files-upload.com/256749/MozillaFirefoxPlugin.rar.html - The browser tab has it's own statusbar, which doesn't look good if the other statusbar is there too. In addition, it has a gripper in the lower right corner (usually for resizing a window) but it is unusable. When in tab mode, the browser should not have a gripper in its' status bar. Fixed! Now Browser control uses program status bar instead of his own. - You have two ways of changing the Renderer. Through the View menu or the View toolbar. But if you use one to change, the other one stays selected on the old Renderer! I have done similar UI things and I recommend making a function handle the MenuOpening event for both, to determine which renderer is being used and then to checkmark the appropriate menu option. There are other ways of fixing it but I find this way works best for me. Fixed! - When using File > Open, the menu stays open while you are using the dialog. This doesn't fit with traditional Windows open dialogs (the menu closes before the dialog appears) and the menu can also sometimes obscure the dialog. I don't know how to fix this. I will ask friends! - Typo... "Standart Editor" In both File > New and File > Open. I think you mean "Standard". True! Fixed! This is for now. The other thing I will fix tonight, cuz now i have no time. 10x again! Download this to check if everything is OK: http://nstudio.hit.bg/BIN.rar (I know that program crashes when you try to close FileSearch window. I am thinking on it.)

NRPG- 05-30-2007

- The "Close" and "Save As" options are not disabled when there are no documents open. Fixed! - When opening a file, you should be able to determine which editor to use based on the file extension, the user should not have to explicitly select one. In cases where you might want to override the extension, the user should be able to explicitly select one, but there should be a general purpose Open dialog which can autoselect an editor to use (Visual Studio handles this good by making the Open button in the dialog a dropdown button which allows you to pick another editor directly from the Open dialog, but you may find it not worth the effort to do all the dirty work needed to change the dialog). Interesting... I will thing on it!

Forumer™ is Voted #1 Free Forum Hosting provider
Build your own community today with the largest message board hosting company.