Обсуждение: Re: About pgAdmin III
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 07 September 2003 19:11 > To: Dave Page > Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] About pgAdmin III > > >So what you're saying is, if you want to develop complex > >views/functions, don't use the nice tools we provide, do it the hard > >way? If so, then you've completely missed the whole point of the > >pgAdmin project :-( > > > What I say is that if view or function gets big, the wizard features > become minor. I use the property dialog to create a skeleton, > and fill > it later in plain sql. The reengineered sql makes it quite easy... Yes, but hardly friendly. I cannot see SQL Enterprise manager docs saying 'if your stored proc becomes too large to edit easily, edit it by hand in the query analyser instead'... > >You should be able to edit any object through it's > properties dialogue, > >no matter how complex - you cannot start dismissing them > because they > >become too big - that's just ridiculous!! > > > Even a swiss army knife has more than one blade: different sizes for > different objects. Yes, but they normally only have one saw blade and don't tell you to gnaw through the branch with your teeth if it's more than 1.5 inches in diameter ;-) > So how big do you need the editing window? > I just checked under win32, I got 153x35 chars on the screen when > maximizing the function dialog, and 156x47 in the view > definition, on a > 1152x864 screen. Is this really too small? Then I'd advise to use a > 4096x3072 screen, and a 4pt font.... I didn't realise the windows were resizable - dialogues generally aren't. In fact looking at them, most of ours aren't. From a good design point of view, this is a bad thing because we have dialogues basically performing the same function (ie showing object properties), that are designed in an inconsistent manner. Perhaps in the next version we should consider a different layout for the dialogues - something that lends itself to resizing more that we can use across the board, and something that is more visually appealing (that's a criticism I've heard a couple of times in the past) as well as functional. > I certainly won't agree to screw up the window handling for > getting some > percent more usable screen size. With resizable dialogues we won't need to. Regards, Dave
Dave Page wrote: >I didn't realise the windows were resizable - dialogues generally >aren't. In fact looking at them, most of ours aren't. From a good design >point of view, this is a bad thing because we have dialogues basically >performing the same function (ie showing object properties), that are >designed in an inconsistent manner. > Oh Dave, what's the point? Most dialogs don't have content that makes resizing senseful, so why should they resize? To have plenty of white space? Stacking modal dialogs is much worse design, and actually dialog design *is* consistent regarding sizing: all dialogs resize in the ranges it makes sense, i.e. not bigger than necessary, and not smaller to prevent hiding of vital information. >Perhaps in the next version we should consider a different layout for >the dialogues - something that lends itself to resizing more that we can >use across the board, and something that is more visually appealing >(that's a criticism I've heard a couple of times in the past) as well as >functional. > How "more visually appealing", more colors, fancy bitmaps? Can't remember fundamental criticism about this, please state the details. >>I certainly won't agree to screw up the window handling for >>getting some >>percent more usable screen size. >> >> > >With resizable dialogues we won't need to. > They are already, and they have been right from the start (for view) and a few days after initial implementation (for function). Especially when talking about functions, there are really other items preventing fast development than shape and smell of a dialog, I'm talking about the poor debugging (i.e. non-existent) debugging facilities for plpgsql. I'm thinking about intelligent support for that (not in a modal dialog of course) Regards, Andreas
I don't agree, there is a problem fitting greek translations in the dialogs. The same occurs with some other languages too. Pgadmin has become a "global" tool, and it would be nice if the designers considered the user's opinion from the other part of world! BTW, pgadmin's functionality is in the dialogs: FULL of features. Regards Yiannis Pailas -------------------- --- Andreas Pflug <pgadmin@pse-consulting.de> έγραψε: > Dave Page wrote: > > >I didn't realise the windows were resizable - > dialogues generally > >aren't. In fact looking at them, most of ours > aren't. From a good design > >point of view, this is a bad thing because we have > dialogues basically > >performing the same function (ie showing object > properties), that are > >designed in an inconsistent manner. > > > Oh Dave, what's the point? > Most dialogs don't have content that makes resizing > senseful, so why > should they resize? To have plenty of white space? > Stacking modal dialogs is much worse design, and > actually dialog design > *is* consistent regarding sizing: all dialogs resize > in the ranges it > makes sense, i.e. not bigger than necessary, and not > smaller to prevent > hiding of vital information. > > >Perhaps in the next version we should consider a > different layout for > >the dialogues - something that lends itself to > resizing more that we can > >use across the board, and something that is more > visually appealing > >(that's a criticism I've heard a couple of times in > the past) as well as > >functional. > > > How "more visually appealing", more colors, fancy > bitmaps? Can't > remember fundamental criticism about this, please > state the details. > > >>I certainly won't agree to screw up the window > handling for > >>getting some > >>percent more usable screen size. > >> > >> > > > >With resizable dialogues we won't need to. > > > They are already, and they have been right from the > start (for view) and > a few days after initial implementation (for > function). > Especially when talking about functions, there are > really other items > preventing fast development than shape and smell of > a dialog, I'm > talking about the poor debugging (i.e. non-existent) > debugging > facilities for plpgsql. I'm thinking about > intelligent support for that > (not in a modal dialog of course) > > Regards, > Andreas > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings ____________________________________________________________ Do You Yahoo!? Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
Γιάννης Παΐλας wrote: >I don't agree, > >there is a problem fitting greek translations in the >dialogs. The same occurs with some other languages >too. > > Translations not fitting can't be an argument for sizable dialogs, we already had this discussion. There are fonts out there that are corrupted (if we tried to have Arabian on such a system, the table dialog would be about 1500 pixel in height!!!), and these have to be corrected. We see fonting problems even with english if fonts don't fit. We don't like accidential display, instead pgAdmin3 should look as designed on *all* systems. If your font doesn't fit, tell us about your system (and upload your translation even if incomplete so we can see the problem), to give us the opportunity to find the reason. Regards, Andreas
Le Lundi 8 Septembre 2003 00:12, vous avez écrit : > there is a problem fitting greek translations in the > dialogs. The same occurs with some other languages > too. Dear Yannis, Your translation was publised. Thanks for your fast delivery. To answer your question from my point of view: - Dialogs we designed with English text, with approx. 30% more space left. We ask translators to shorten their messages in order to fit in the given space. Sometimes it is difficult. We can only rely on the experience of translators to tell a dialog is large enough or not. - Here and there, problems may arise. In the case of French, I had problems with the "Option" and "Export data to file" dialogs. These two dialogs probably need enlargement. Yiannis, could you outline the dialogs which were difficult to translate into Greek after shortening messages? Cheers, Jean-Michel Pouré
Jean-Michel POURE wrote: >Le Lundi 8 Septembre 2003 00:12, vous avez écrit : > > >>there is a problem fitting greek translations in the >>dialogs. The same occurs with some other languages >>too. >> >> > >Dear Yannis, > >Your translation was publised. Thanks for your fast delivery. > >To answer your question from my point of view: > >- Dialogs we designed with English text, with approx. 30% more space left. > There are place where 0 % is left, because the developer didn't care. Who was that sloppy guy?!? Oops, me... > We ask translators to shorten their messages in order to fit in the given space. >Sometimes it is difficult. We can only rely on the experience of translators >to tell a dialog is large enough or not. > I had a brief look at the greek texts and didn't find it really horrible. Most cases are where even the english text is quite long, e.g. "source encoding" for conversions. This can easily be abbrevated to "source enc." without sacrificing meaning too much. Somebody who doesn't understand what "source enc." might mean in this context probably won't understand the long form either and should hit F1 to learn about it. We have a style guide for property dialogs, reserving 90 units for the explanation (actual pixel count depends on OS), which should be enough. I really wouldn't like to deviate from the style guide case by case, and enlarging this would make most dialogs look strange. > >- Here and there, problems may arise. In the case of French, I had problems >with the "Option" and "Export data to file" dialogs. These two dialogs >probably need enlargement. > I had a look at these two. I really was a bit too mean with space in the export dialog. I just enlarged it by 60 units. Option is a different story. There's an awful lot of text in it, trying to explain verbosely what each option means, which finally can't succeed. We grew this dialog already several times, its proportions are becoming ugly. I'd suggest all translators to do their best to express what's going on in the limited space, if still unclear the user needs to hit F1. The Log Level radiobox resizes itself, I shifted it 25 units to the left so it can grow a bit more. Regards, Andreas
Hi for all Found bug, then I try to create constraint, unique, you generate SQL code to try to make primary key. About Edit window. You are right, but may be button APPLY for apply my changes in function text.. is it useful maybe? Save window position/size, maybe too? Thanks Best regards -----Original Message----- From: Dave Page [mailto:dpage@vale-housing.co.uk] Sent: Sunday, September 07, 2003 10:58 PM To: Andreas Pflug Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org Subject: RE: [pgadmin-hackers] About pgAdmin III > -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 07 September 2003 19:11 > To: Dave Page > Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] About pgAdmin III > > >So what you're saying is, if you want to develop complex > >views/functions, don't use the nice tools we provide, do it the hard > >way? If so, then you've completely missed the whole point of the > >pgAdmin project :-( > > > What I say is that if view or function gets big, the wizard features > become minor. I use the property dialog to create a skeleton, > and fill > it later in plain sql. The reengineered sql makes it quite easy... Yes, but hardly friendly. I cannot see SQL Enterprise manager docs saying 'if your stored proc becomes too large to edit easily, edit it by hand in the query analyser instead'... > >You should be able to edit any object through it's > properties dialogue, > >no matter how complex - you cannot start dismissing them > because they > >become too big - that's just ridiculous!! > > > Even a swiss army knife has more than one blade: different sizes for > different objects. Yes, but they normally only have one saw blade and don't tell you to gnaw through the branch with your teeth if it's more than 1.5 inches in diameter ;-) > So how big do you need the editing window? > I just checked under win32, I got 153x35 chars on the screen when > maximizing the function dialog, and 156x47 in the view > definition, on a > 1152x864 screen. Is this really too small? Then I'd advise to use a > 4096x3072 screen, and a 4pt font.... I didn't realise the windows were resizable - dialogues generally aren't. In fact looking at them, most of ours aren't. From a good design point of view, this is a bad thing because we have dialogues basically performing the same function (ie showing object properties), that are designed in an inconsistent manner. Perhaps in the next version we should consider a different layout for the dialogues - something that lends itself to resizing more that we can use across the board, and something that is more visually appealing (that's a criticism I've heard a couple of times in the past) as well as functional. > I certainly won't agree to screw up the window handling for > getting some > percent more usable screen size. With resizable dialogues we won't need to. Regards, Dave
Dmitry A. Mordovin wrote: >Hi for all > >Found bug, then I try to create constraint, unique, you generate SQL >code to try to make primary key. > >About Edit window. You are right, but may be button APPLY for apply my >changes in function text.. is it useful maybe? > Added to TODO, but maybe this isn't implemented. Instead, there might be a plpgsql debugger coming... Regards, Andreas