Thread: Dry Run Mode, + W9X
Hello all, What do you people think of adding a so-called "dry run" mode to pgAdmin? Basically, what I want is to be able to step through all the dialogs and forms and the rest of the UI in some test mode so that I can see all the GUI elements and their appearance w/o actually performing any underlying operations. This would be extremely useful for my translation work and usability testing. There some cases when I translate strings they don't fit within the allotted space in a dialog, etc, and I cannot test it/force it to appear other than in real situation. So, I'd like to have some kind of preview of the UI before I do any actual stuff (heck, I don't even always have the server available to test most common scenarios against!). For example, I'd like to be able to run through the following scenario and see all corresponding UI paths w/o actually making a connection: - "Add server" - Enter some dummy values - First pgAdmin pretends that the connection failed. - Then, the UI pretends the connection is successfully made and adds a fake server with fake catalog data - I can browse through the fake data. Likewise, for other functions of the UI. This would greatly help me for example not to only translate, but also test my translations where I have any Windows version (including 9X) and w/o having ability to connect to a postgres server. Since I move around quite a lot, this is a frequent scenario. Others may find it useful too. I have some ideas on implementing this. This option targets primarily the developers/translators of pgAdmin. How likely such a patch is to be accepted by the team? (Not for 1.2 of course, but for the next release). It can be some debug option... Thanks, -- Serguei A. Mokhov
Serguei Mokhov wrote: > Hello all, > > What do you people think of adding a so-called > "dry run" mode to pgAdmin? Basically, what I want > is to be able to step through all the dialogs and forms and > the rest of the UI in some test mode so that I can > see all the GUI elements and their appearance w/o > actually performing any underlying operations. This seems a good idea to support translators. But it has some caveats which have to be considered while implementing. E.g. a dummy server may not be written to the registry when exiting the app. Many strings which are not easily understandable without context are probably error messages. A translator would still have the problem "when is this string xyz used". Win9x support is still not implementable. Our weak 9x support is not a database connection issue; it's the operating system lacking proper unicode support, which is unfortunately *the* limiting factor for your "dry mode" target audience. Regards, Andreas
----- Original Message ----- From: "Andreas Pflug" <pgadmin@pse-consulting.de> Sent: September 19, 2004 1:29 PM > Serguei Mokhov wrote: > > Hello all, > > > > What do you people think of adding a so-called > > "dry run" mode to pgAdmin? Basically, what I want > > is to be able to step through all the dialogs and forms and > > the rest of the UI in some test mode so that I can > > see all the GUI elements and their appearance w/o > > actually performing any underlying operations. > > This seems a good idea to support translators. But it has some caveats > which have to be considered while implementing. E.g. a dummy server may > not be written to the registry when exiting the app. Yes, the point is NOT to use the registry at all in the dry run mode. It is not always I have a permission to do so where I am doing the actual work. > Many strings which are not easily understandable without context are > probably error messages. A translator would still have the problem "when > is this string xyz used". For myself, the error messages are least of my worries. Most problems I have are with field labels that cannot fit within a given container when translated, so a part of a label's text gets truncated. For the dry run mode you need little context, you just show all possible dialogs and forms for a given action. > Win9x support is still not implementable. Our weak 9x support is not a > database connection issue; it's the operating system lacking proper > unicode support, which is unfortunately *the* limiting factor for your > "dry mode" target audience. Nonetheless, Dave Page built 9X binaries for 1.0.2, which work perfectly okay for me. Another reason is the registry usage, but as I said, I want to avoid the use of registry in the dry run mode altogether. So, if I address the caveats and other issues that come up and if the change is not too invasive, I have some chances for the work to be applied when I contribute it? > Regards, > Andreas -s
Serguei Mokhov wrote: > > For myself, the error messages are least of my worries. Most problems I have > are with field labels that cannot fit within a given container when translated, > so a part of a label's text gets truncated. For the dry run mode you need > little context, you just show all possible dialogs and forms for a given > action. OK, that's reasonable. > > Nonetheless, Dave Page built 9X binaries for 1.0.2, which work perfectly okay > for me. Another reason is the registry usage, but as I said, I want to > avoid the use of registry in the dry run mode altogether. Our project doesn't contain non-unicode support any more. > > So, if I address the caveats and other issues that come up and > if the change is not too invasive, I have some chances for the > work to be applied when I contribute it? Yes, but not before 1.2 release (which will not take too much time) It will be hard work: - many comboboxes are filled from db, you might even force uncatched errors here. - some (few) strings are exchanged at runtime. First that comes to my mind is "Users/Groups" on the privileges tab, selectable by "display users in privileges". You could scan for CTRL_STATIC in the sources. Regards, Andreas
----- Original Message ----- From: "Andreas Pflug" <pgadmin@pse-consulting.de> Sent: September 19, 2004 2:17 PM > > Nonetheless, Dave Page built 9X binaries for 1.0.2, which work perfectly okay > > for me. Another reason is the registry usage, but as I said, I want to > > avoid the use of registry in the dry run mode altogether. > > Our project doesn't contain non-unicode support any more. Oops. I guess that passed by me unnoticed. :( > > So, if I address the caveats and other issues that come up and > > if the change is not too invasive, I have some chances for the > > work to be applied when I contribute it? > > Yes, but not before 1.2 release (which will not take too much time) Of course not as I said in my original post. And the feature freeze is taking place. > It will be hard work: > - many comboboxes are filled from db, you might even force uncatched > errors here. > - some (few) strings are exchanged at runtime. First that comes to my > mind is "Users/Groups" on the privileges tab, selectable by "display > users in privileges". You could scan for CTRL_STATIC in the sources. It's okay. Life is not easy either. Thanks for the pointers! > Regards, > Andreas -s