> > > BTW what part of the artical is relevant to what follows ? > Is it ti guide me, what objects are, and, how to program them > or how should these behave ? > > It's describe a pattern (not necessarily related to OOP) which IMO help you organize the code to avoid inconsistencies. The command pattern defines a centralized action to be triggered by any events on application, a button, a menu option, a keyboard shortcut, or by code too. If you treat each action isolated you will get inconsistencies since it's hard keep all places synchronized.
> > > Well, the word "inconsistencies" is a relevant term. > It is relevant to "what one is used to" and what he encounters > somewhere which is not similar to "he is used". So, in this > context what you see as an "inconsistency" may be a feature for other. > > As bug is not a feature, inconsistency is not a feature. GUI can't have inconsistency, GUI need to be predictable. > > > The "close X" button is a generic one and is present on any window visible > on the desktop. It is usual that at some point of time one accidently > clicks > hbIDE's X whereever his aim was another window but he could not recognize > as hbIDE was partially covered by some other one. So the alert is issued > if he is not making a mistake. Contray to this Menubar->Files->Exit option > and "Exit" icon on the toolbar is specific to hbIDE only and user will ever > click them knowingly, so no alert. > This is I call inconsistent. In case of accident, the user can open it again without a danger. The user wants be cautious? Ok, IDE need have a option to all close application triggers request a confirmation. IDE need to be flexible. Each programmer has its own workflow. > I do not want it to get "displaced" by the user and always have > them handy and at the same place for easy and fast access. > > But the user could think different. The user can use only keyboard or it can prefer all toolbars on top, or some on the monitor 1 and others on monitor 2. I think toolbars need to be more granular too. Toolbars should mirror (or almost mirror) the menus. Should have a file toolbar, a edit toolbar, a view toolbar, a build toolbar, etc, etc. These can be floatable, though, persoanlly I do not like them to hang > anywhere because of always-available-same position. > Subject to group decision. > > Give options to user is always a good decision on a IDE. Remember each user have a different monitor setup. Think about 1, 2, 3 monitors, thinks about full screen and wide screen, or portrait x landscape position, or entire monitor to IDE x shared screen with another app. > > > > All panels detached (not docked) lost visibility when HbIDE is closed and > > opened again. > > > > Yep, this should be like this. I will implement. > Subject to group decision. > > It's ok if panels can be docked on secondary monitor. > > For some panels should be modal windows like you done right with > Keyboard > > Mapping panel, Tool and Utilities (although it can open just by toolbar): > > Project Properties (should be open by Project menu) > > Compiler Environments > > Theme Manager > > Code Skeletons > > Last three should be Setup options like KB Mapping and Tool&Util. > > > > It is OK both ways, what is the harm in current implementation ? > > No big harm, but no standard in any application with good GUI design. For it's ok, but HbIDE looks less professional. This is inconsistent. Setup has rare use. I don't wanna give a bad idea, (please, don't do this): If Theme manager, Comp Env, etc should be a panel, KB Maps, T&U should be too. Setup is modal window. Sorry, i have difficulty to explain with more details in English. > > > Editor as a panel? I don't think so. A menu and/or a drop down button on > > tab > > bar is more appropriate. > > > > No, I find it more convinient than menus. > > And I find a lot more convenient haven't a panel for this. I respect your and others taste, I and others have another taste or need. Again, IDE need to be flexible. In my personal need I can't have this panel open taking a precious space of my screen. Main "editors" (for me this is "tabs") are on top of editor and collateral should be reachable by a drop down and keyboard shortcut (to navigate to back and forward, I didn't try this yet) and to consistency (not for my need) the same should be in menus too. Menus is almost useless for me, I am writing about this just to be consistent. I am not inventing nothing here, I just write what I see on applications like that. > > > Find in Files panel looses his position after HbIDE be closed. > > > > I could not follow you, please explain a bit more. > > Maybe the real problem is the panel can't be docked on another monitor. When I reopen HbIDE and I manually turn visible my panels on secondary monitor (like I left before close IDE), Documentation panel, Function List panel are on same position that I left last time (floating of course, as I left), but Find in Files have a different behavior and it shows floating on primary monitor in different position that I left. My concern is about inconsistency about the behavior. If there is this inconsistency, I think others panel have or could have inconsistency. You need to find a way to all panel have the same behavior whatever you program them. I didn't read the code in deep but I think that each panel have its own code to control the panel behavior. If this is true, it's not a consistent way to go. > It opens in the last exit state always, even if you closed it maximized. > What is your point exactly ? > > I exit maximized always but I reopen and HbIDE is not in maximized state. > > Are you saying that when docking widget are tried to be placed on 2nd > monitor, > you cannot do so ? Or, when placed on 2nd and you exit hbIDE, these are > not opened at the same 2nd monitor ? I did not experiment yet, but I think > you can place them on 2nd monitor > I can put panel floating on 2nd monitor but not dock on a windows on 2nd monitor. I can dock if I resize window to my 2nd monitor too, but this is not multi monitor support. I need get an IDE with appropriate multi monitor support to understand better. Multi monitor It's a little tricky. And I need more "docks" to place my panels. If I didn't lost something I have only right and left docks to drop the panels. With 2 monitor I can have Find, Documentaion, Function List, Snippets (Skeletons), Project files, and the Editor (or editors splitted), all visible at same time on my screen. > > > Command impossible to be select should be grayed on menu and button and > > disabled on keyboard. > > > > Yes, this should be like this. But because of multi-panel/multi source > editsing > instances, I could not achieve this in transparent way. > > You could not achieve this yet or you think you will never achieve this? > View menu use to be next to Edit menu. > > > > No, it must be one before "Help" always. > > Not in any professional application. There is standard rules about this (I am trying find them to you): http://www.softpedia.com/screenshots/VS-Php-for-Visual-Studio-2005_1.png http://www.stylusstudio.com/java_ide_screenshot.html http://www.xharbour.com/images/main/screenshots/vxh-screenshot1.jpg http://download.cnet.com/NetBeans-IDE/3004-2212_4-10628055.html http://eric-ide.python-projects.org/images/eric4-screen-01.png http://wiki.lazarus.freepascal.org/Image:Windows_7.png http://www.andywos.ih.co.za/xmate/xmate_screenshots.htm (the worse example) http://notepad-plus.sourceforge.net/uk/screenshots.php http://sqllib.com.br/v4/index.php?artigo=xDevStudio&page=Recursos (Visualizar) http://mac.softpedia.com/progScreenshots/Komodo-Screenshot-9866.html Search is ok because it is a split from Edit menu > This is read as ISO 8859-13, ISO 8859-14, etc. So I kept it like -n > Anyway it is not an issue at all. > > Of course it's not a big problem, but it's not a issue if you wanna see your user confusing. In usability, when you need to explain, it's wrong. > > > If I am understnding you properly, are you saying in editing instances > word-wrap should be "ON" ? I did not see any programming editor having > this feature. And if some editor has it, I cannot imagine how it will > work for a programmer. Please support your logic. > > Should be a mode to toggle. I know editors which implement this accordingly or not but all usable editors I know support word wrap. Review links above, all them implement this. Today my editor is Notepad++. One of many reasons I choose it because word wrap is working in the right way. I "can't" live without word wrap. > > > I think is unnecessary say that column mode is broken for now, but nice > to > > try. > > > > It is not "broken". > It is just not implemented. > Well, then it's working better than you think :-) Ok, It's not working yet. > > Not probably. It should jump to function body. > > Ok, whatever, but in my IDE this is not working. I miss something? > > > Why toggle mark command is only on toolbar? > > > > Where it should be another place ? > > For consistency, on menu too (I didn't try keyboard yet) Later I will write new review, I will give you some breath ;-) []'s Maniero
_______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
