Good points, I agree with them. Consistency and flexibility as known from other GUIs/IDEs is very important, and IMO in Harbour our job at the moment is not to reinvent IDE idioms, but to follow what's already developed (Eclipse, MSVS). We can be different, if it means better, but ppl have certain expectations when working with IDEs, and we should rather try to satisfy them than forcing something unusual.
my 2 cents. Viktor On 2010 Apr 27, at 17:42, Antonio Maniero wrote: > > 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 _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
