Обсуждение: EditGrid options
Hi Dave, I just had a look at your recent work, and have some remarks. - You know I'm not really a fan of popup windows (especially the modal ones), can't we implement this in a different way? - The sort (filter-to-come) options are not visible. - for very large tables, it's annoying if the query is run immediately when starting the EditGrid, without a chance to restrict it. We might need a second menu entry to EditGrid like "View filtered data" - Maybe we could use a wxNotebook, first tab is the data, tab text shows filter and sort, second tab is "options" - The button sizes on the options dlg don't conform to the latest design guide. Just a hint: when inheriting a dlg from dlgProperty, it will have some handy methods for listviews available, supplying DlgUnit sizing, headers filling the rest of the control, ... Pixels are no legal positioning/sizing units any more. Regards, Andreas
It's rumoured that Andreas Pflug once said: > Hi Dave, > > I just had a look at your recent work, and have some remarks. > > - You know I'm not really a fan of popup windows (especially the modal > ones), can't we implement this in a different way? I don't think it's an unreasonable use of a modal dialogue - I think it's more intuitive than using seperate tab on the main form and having an apply button either update invisible data, or control the tabset. > - The sort (filter-to-come) options are not visible. Not sure what you mean. The filter options aren't visible because I haven't implemented them yet. That's planned for this week, but should be quicker and easier than sort, even with syntax validation. > - for very large tables, it's annoying if the query is run immediately > when starting the EditGrid, without a chance to restrict it. We might > need a second menu entry to EditGrid like "View filtered data" Perhaps an 'auto query' option on the form would be appropriate. A toggle button as per MS Query. > - Maybe we could use a wxNotebook, first tab is the data, tab text > shows filter and sort, second tab is "options" Like I said, I'm not convinced that would be easy to make behave as it should. > - The button sizes on the options dlg don't conform to the latest > design guide. The OK/Cancel are, the others aren't because the text is too long. It would probably just fit in English, but there are other less terse languages as we know. > Just a hint: when inheriting a dlg from dlgProperty, it will have some > handy methods for listviews available, supplying DlgUnit sizing, > headers filling the rest of the control, ... > Pixels are no legal positioning/sizing units any more. I didn't use pixels anywhere did I? Regards, Dave
> -----Original Message----- > From: Dave Page > Sent: 18 October 2003 13:15 > To: pgadmin@pse-consulting.de > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] EditGrid options > > It's rumoured that Andreas Pflug once said: > > > > Just a hint: when inheriting a dlg from dlgProperty, it > will have some > > handy methods for listviews available, supplying DlgUnit sizing, > > headers filling the rest of the control, ... > > Pixels are no legal positioning/sizing units any more. > > I didn't use pixels anywhere did I? Oh yes I did - fixed! Regards, Dave.
Dave Page wrote:
>It's rumoured that Andreas Pflug once said:
>
>
>>Hi Dave,
>>
>>I just had a look at your recent work, and have some remarks.
>>
>>- You know I'm not really a fan of popup windows (especially the modal
>>ones), can't we implement this in a different way?
>>
>>
>
>I don't think it's an unreasonable use of a modal dialogue - I think it's
>more intuitive than using seperate tab on the main form and having an
>apply button either update invisible data, or control the tabset.
>
>
I didn't spent too much time thinking about how it should look, just 5
seconds, but a modal dialog is the 0.1 second solution...
>>- The sort (filter-to-come) options are not visible.
>>
>>
>
>Not sure what you mean. The filter options aren't visible because I
>haven't implemented them yet. That's planned for this week, but should be
>quicker and easier than sort, even with syntax validation.
>
>
I mean that applied filter (as soon as it is implemented) and sorting
should be visible, not hidden in that options dialog. This is especially
senseful if you insert something out of the scope of the filter, and do
a refresh ("hell, where did my data go!")
>>- for very large tables, it's annoying if the query is run immediately
>>when starting the EditGrid, without a chance to restrict it. We might
>>need a second menu entry to EditGrid like "View filtered data"
>>
>>
>
>Perhaps an 'auto query' option on the form would be appropriate. A toggle
>button as per MS Query.
>
>
No, thats *not* what I'm talking about.
I'll be using EditGrid normally for small tables, thus I need autoquery
90% of the time (no filter, no sort). The other 10 % might be very long
running, thus I'd like the option to enter the grid, having the chance
to filter before the query executes.
This would look&feel very dirty if filtering is done using a modal
dialog....
>>- Maybe we could use a wxNotebook, first tab is the data, tab text
>>shows filter and sort, second tab is "options"
>>
>>
>
>Like I said, I'm not convinced that would be easy to make behave as it
>should.
>
>
Notebook was just the first thought, propose something better.
Some expandable/collapsable options pane would be possible.
>>- The button sizes on the options dlg don't conform to the latest
>>design guide.
>>
>>
>
>The OK/Cancel are, the others aren't because the text is too long. It
>would probably just fit in English, but there are other less terse
>languages as we know.
>
>
How about abbrevations if it really doesn't fit? This looks *ugly*!
>>Just a hint: when inheriting a dlg from dlgProperty, it will have some
>>handy methods for listviews available, supplying DlgUnit sizing,
>>headers filling the rest of the control, ...
>>Pixels are no legal positioning/sizing units any more.
>>
>>
>
>I didn't use pixels anywhere did I?
>
>
>
Yep, you already found it. Still, I wonder why you don't use the
existing methods. Creating the lb columns is a one-liner.
Regarding the ctlSQLBox xrc attachment: IMHO it's saver to implement a
custom xrc handler for this; I'll check it in soon.
Regards,
Andreas
It's rumoured that Andreas Pflug once said:
> I didn't spent too much time thinking about how it should look, just 5
> seconds, but a modal dialog is the 0.1 second solution...
>
What is your problem with modal dialogues? They are used in all manner of
applications for setting options such as these. Not using modal dialogues
for things that are quick open/modify/close options can lead to problems
for the inexperienced user when they accidently leave two or three open
and then lose track of the parents. iirc, it was for this exact reason
that you made the add column dialogue modal (might not have been that one,
but you know what I mean).
Few can argue that Microsoft don't produce some of the best user
interfaces around in their mainstream products, yet they have no problem
using modal dialogues in situations like this.>
> I mean that applied filter (as soon as it is implemented)
>
It is now.
>
> and sorting
> should be visible, not hidden in that options dialog. This is
> especially senseful if you insert something out of the scope of the
> filter, and do a refresh ("hell, where did my data go!")
>
That's an easy fix. For example, Outlook puts a 'Filter Applied' label at
the top of the listbox.>
> No, thats *not* what I'm talking about.
> I'll be using EditGrid normally for small tables, thus I need autoquery
> 90% of the time (no filter, no sort). The other 10 % might be very
> long running, thus I'd like the option to enter the grid, having the
> chance to filter before the query executes.
> This would look&feel very dirty if filtering is done using a modal
> dialog....
>
I think it makes little difference how the sort/filter is implemented to
this (completely seperate) problem. What you are asking for is a second
view data menu option that doesn't auto query, however that would be ugly
as well. As it stands now, you are no worse off than in 1.0.0. With an
auto query toggle button, those that know they are working on large data
sets can turn it off in advance, or on first use during the task.
Any other way will either look like a kludge, or inconvenience to those
who want to actually view data when the select the option, not be asked if
they want to see the data as well.>
> Notebook was just the first thought, propose something better.
> Some expandable/collapsable options pane would be possible.
>
That's certainly more palatable than a notebook, but I'm still not
convinced it's the best way.>
> How about abbrevations if it really doesn't fit? This looks *ugly*!
>
OK, now I get it. Clearly you had too much beer last night :-). How can
you possibly say that abbreviated text will look better than buttons that
are 25% or so wider than normal, particularly when those button are
uniform sized in their own group, fit into the space they are positioned
in properly, and are visually seperate from any other buttons of different
size?
If you are going to try to enforce a style guide without consultation with
the rest of us first, at least make sure that you specify objects big
enough for perfectly reasonable captions.>
> Yep, you already found it. Still, I wonder why you don't use the
> existing methods. Creating the lb columns is a one-liner.
>
2 lines of simplified code is more efficient than 1 line calling an
overcomplicated (for my purpose) function. Not that it matters from a
performance pov, but it is more easilt understandable.>
> Regarding the ctlSQLBox xrc attachment: IMHO it's saver to implement a
> custom xrc handler for this; I'll check it in soon.
>
A good idea. How would xrced cope though? As far as I'm aware it's still
the best (free) xrc editor, and I'd hate to have to lose use of it for the
sake of a couple of lines of code.
BTW, anyone else have any opinions on the dialogue issue?
Regards, Dave.
Dave Page wrote:
>It's rumoured that Andreas Pflug once said:
>
>
>>I didn't spent too much time thinking about how it should look, just 5
>>seconds, but a modal dialog is the 0.1 second solution...
>>
>>
>>
>What is your problem with modal dialogues? They are used in all manner of
>applications for setting options such as these. Not using modal dialogues
>for things that are quick open/modify/close options can lead to problems
>for the inexperienced user when they accidently leave two or three open
>and then lose track of the parents. iirc, it was for this exact reason
>that you made the add column dialogue modal (might not have been that one,
>but you know what I mean).
>
>
I'm against popup dialogs at all! Certainly, in this case if used at
all, it must be modal.
>Few can argue that Microsoft don't produce some of the best user
>interfaces around in their mainstream products, yet they have no problem
>using modal dialogues in situations like this.>
>
>
The stacking of modal dialogs that MS performs is one of their worst ui
sins!
The options dialog would make sense if it would modify the behaviour of
the EditGrid itself (persistent options like bg color, ...), but not for
the data.
>>I mean that applied filter (as soon as it is implemented)
>>
>>
>>
>It is now.
>
>
>>and sorting
>>should be visible, not hidden in that options dialog. This is
>>especially senseful if you insert something out of the scope of the
>>filter, and do a refresh ("hell, where did my data go!")
>>
>>
>>
>That's an easy fix. For example, Outlook puts a 'Filter Applied' label at
>the top of the listbox.>
>
>
Could be, I'm not sure if we can have a 3rd line in the header control.
>>No, thats *not* what I'm talking about.
>>I'll be using EditGrid normally for small tables, thus I need autoquery
>> 90% of the time (no filter, no sort). The other 10 % might be very
>>long running, thus I'd like the option to enter the grid, having the
>>chance to filter before the query executes.
>>This would look&feel very dirty if filtering is done using a modal
>>dialog....
>>
>>
>>
>I think it makes little difference how the sort/filter is implemented to
>this (completely seperate) problem.
>
Not quite. Popup dialog wouldn't be a good idea.
> What you are asking for is a second
>view data menu option that doesn't auto query, however that would be ugly
>as well. As it stands now, you are no worse off than in 1.0.0. With an
>auto query toggle button, those that know they are working on large data
>sets can turn it off in advance,
>
How that? In global options? That's nasty. Second menu is easier to use.
>or on first use during the task.
>Any other way will either look like a kludge, or inconvenience to those
>who want to actually view data when the select the option, not be asked if
>they want to see the data as well.>
>
>
>>Notebook was just the first thought, propose something better.
>>Some expandable/collapsable options pane would be possible.
>>
>>
>>
>That's certainly more palatable than a notebook, but I'm still not
>convinced it's the best way.>
>
>
So be positive, and make proposals.
>>How about abbrevations if it really doesn't fit? This looks *ugly*!
>>
>>
>>
>OK, now I get it. Clearly you had too much beer last night :-). How can
>you possibly say that abbreviated text will look better than buttons that
>are 25% or so wider than normal, particularly when those button are
>uniform sized in their own group, fit into the space they are positioned
>in properly, and are visually seperate from any other buttons of different
>size?
>
>
So get rid of that buttons.
>If you are going to try to enforce a style guide without consultation with
>the rest of us first, at least make sure that you specify objects big
>enough for perfectly reasonable captions.>
>
>
There's some aesthetical limit on button sizes. IMHO this limit is
nearly reached. Standard size for MS buttons is (46,15d), btw.
>>Yep, you already found it. Still, I wonder why you don't use the
>>existing methods. Creating the lb columns is a one-liner.
>>
>>
>>
>2 lines of simplified code is more efficient than 1 line calling an
>overcomplicated (for my purpose) function. Not that it matters from a
>performance pov, but it is more easilt understandable.>
>
>
I'm counting 5 lines... CreateListColumns takes two strings as
left/right header, and the size of the left header in DlgUnits, do you
need less?
>>Regarding the ctlSQLBox xrc attachment: IMHO it's saver to implement a
>>custom xrc handler for this; I'll check it in soon.
>>
>>
>>
>A good idea. How would xrced cope though? As far as I'm aware it's still
>the best (free) xrc editor, and I'd hate to have to lose use of it for the
>sake of a couple of lines of code.
>
>
We won't get around it anyway (wxCalendarBox on the way). The control
type has to be changed in a text editor. After that, id/pos/size/style
can be edited in XRCed as usual.
Regards,
Andreas
It's rumoured that Andreas Pflug once said: > Dave Page wrote: > >>That's an easy fix. For example, Outlook puts a 'Filter Applied' label >>at the top of the listbox.> >> >> > Could be, I'm not sure if we can have a 3rd line in the header control. > > It could easily be just above the control, only affecting the position of the control when required, or there permanently, in a shaded colour to make it look intended when there is no text there.> >> What you are asking for is a second >>view data menu option that doesn't auto query, however that would be >>ugly as well. As it stands now, you are no worse off than in 1.0.0. >>With an auto query toggle button, those that know they are working on >>large data sets can turn it off in advance, >> > How that? In global options? That's nasty. > No, like I originally suggested, a toggle button in the button bar who's state is remembered between invocations. Similar to the auto-update button in MS query, or XRCed to name just a couple.> > Second menu is easier to use. > What would you have: View Data View Data (but not immediately) ;-) Seriously though, I'm happy to entertain that idea if you can think of a way it doesn't sound ridiculous.> >>That's certainly more palatable than a notebook, but I'm still not >>convinced it's the best way.> >> > So be positive, and make proposals. > I did - I committed it to CVS. That seems like the natural way to do it to me, which is why I implemented it that way. I'm happy to be corrected if I'm wrong, or consider other opinions, but so far you have not convinced me that my original design is not the best way. That's why I asked for other opinions at the end of my last message - I'll go with the majority opinion (and will happily do any required recoding). Come on people - don't be shy!! > >>>How about abbrevations if it really doesn't fit? This looks *ugly*! >>> >>OK, now I get it. Clearly you had too much beer last night :-). How can >>you possibly say that abbreviated text will look better than buttons >>that are 25% or so wider than normal, particularly when those button >>are uniform sized in their own group, fit into the space they are >>positioned in properly, and are visually seperate from any other >>buttons of different size? >> > So get rid of that buttons. > And replace them with what? A neural interface? ;-) > >>If you are going to try to enforce a style guide without consultation >>with the rest of us first, at least make sure that you specify objects >>big enough for perfectly reasonable captions.> >> >> > There's some aesthetical limit on button sizes. IMHO this limit is > nearly reached. Standard size for MS buttons is (46,15d), btw. > Yes, but they enlarge as required. Right-click, Properties, and then click the desktop tab on UK Windows XP (and probably others) and you'll see a 'Customise Desktop' button which is much bigger, but doesn't look wrong because it's logically seperate from other buttons of standard size.> > I'm counting 5 lines... CreateListColumns takes two strings as > left/right header, and the size of the left header in DlgUnits, do you > need less? > OK, 5. I'm not near the code right now. It still does a lot less but I'll change it if you insist. Regards, Dave.
Dave Page wrote: >It's rumoured that Andreas Pflug once said: > > >>Dave Page wrote: >> >> >> >>>That's an easy fix. For example, Outlook puts a 'Filter Applied' label >>>at the top of the listbox.> >>> >>> >>> >>> >>Could be, I'm not sure if we can have a 3rd line in the header control. >> >> >> >> >It could easily be just above the control, only affecting the position of >the control when required, or there permanently, in a shaded colour to >make it look intended when there is no text there.> > > This would be the natural position to sort and filter too. Without buttons... If filtering is somehow integrated in each column, this works as kind of wizard (the freetext form will provoke problems with column name quoting, which isn't needed anywhere throughout pgAdmin but here). BTW, filter validation is fine, but this is another message box, even if ok, giving a beep each time! Can't we handle this silently, in the status line? We don't need a window that forces the user's attention to the problem, he's already aware that there might be one. And this is the only dialog that has a single non-standard sized button on the left side... >>>What you are asking for is a second >>>view data menu option that doesn't auto query, however that would be >>>ugly as well. As it stands now, you are no worse off than in 1.0.0. >>>With an auto query toggle button, those that know they are working on >>>large data sets can turn it off in advance, >>> >>> >>> >>How that? In global options? That's nasty. >> >> >> >No, like I originally suggested, a toggle button in the button bar who's >state is remembered between invocations. Similar to the auto-update button >in MS query, or XRCed to name just a couple.> > > Please don't mention MS query, I've been suffering from this tool too often... >>Second menu is easier to use. >> >> >> >What would you have: > >View Data >View Data (but not immediately) > >;-) Seriously though, I'm happy to entertain that idea if you can think of >a way it doesn't sound ridiculous.> > > View Data View Data after the user has entered a filter and pushed the update button :o) seriously: View filtered Data. Instead of showing a collapsed dialog, with data readily queried, the expanded view without data is shown >>>That's certainly more palatable than a notebook, but I'm still not >>>convinced it's the best way.> >>> >>> >>> >>So be positive, and make proposals. >> >> >> >I did - I committed it to CVS. That seems like the natural way to do it to >me, which is why I implemented it that way. I'm happy to be corrected if >I'm wrong, or consider other opinions, but so far you have not convinced >me that my original design is not the best way. >That's why I asked for other opinions at the end of my last message - I'll >go with the majority opinion (and will happily do any required recoding). >Come on people - don't be shy!! > > >>>>How about abbrevations if it really doesn't fit? This looks *ugly*! >>>> >>>> >>>> >>>OK, now I get it. Clearly you had too much beer last night :-). How can >>>you possibly say that abbreviated text will look better than buttons >>>that are 25% or so wider than normal, particularly when those button >>>are uniform sized in their own group, fit into the space they are >>>positioned in properly, and are visually seperate from any other >>>buttons of different size? >>> >>> >>> >>So get rid of that buttons. >> >> >> >And replace them with what? A neural interface? ;-) > > >>>If you are going to try to enforce a style guide without consultation >>>with the rest of us first, at least make sure that you specify objects >>>big enough for perfectly reasonable captions.> >>> >>> >>> >>> >>There's some aesthetical limit on button sizes. IMHO this limit is >>nearly reached. Standard size for MS buttons is (46,15d), btw. >> >> >> >Yes, but they enlarge as required. Right-click, Properties, and then click >the desktop tab on UK Windows XP (and probably others) and you'll see a >'Customise Desktop' button which is much bigger, but doesn't look wrong >because it's logically seperate from other buttons of standard size.> > > >>I'm counting 5 lines... CreateListColumns takes two strings as >>left/right header, and the size of the left header in DlgUnits, do you >>need less? >> >> >> >OK, 5. I'm not near the code right now. It still does a lot less but I'll >change it if you insist. > > It really does exactly the same. Actually, I was quite happy to have this method, changing from pixels to DlgUnits was easy. Regards, Andreas
It's rumoured that Andreas Pflug once said: > Dave Page wrote: > > This would be the natural position to sort and filter too. Without > buttons... > I still don't see how you would do it without buttons... > > If filtering is somehow integrated in each column, this works as kind > of wizard (the freetext form will provoke problems with column name > quoting, which isn't needed anywhere throughout pgAdmin but here). > Yes, I'm aware of that issue. The problem is that doing it in a purely GUI kindof way is quite tricky (see the QB for an example). With a simple value per column, ANDed together, things are easy, but more complex expressions get very difficult, for example: (((id >= 20 AND id < 40) AND parent IS NOT NULL) OR parent IS NULL) I suspect I know what your response to that will be though :-) > BTW, filter validation is fine, but this is another message box, even > if ok, giving a beep each time! Can't we handle this silently, in the > status line? > We don't need a window that forces the user's attention to > the problem, he's already aware that there might be one. The message only tells the user if there is a problem if the user presses the button. A positive action (pressing the button) would normally be expected to generate an active response (the message box) rather than a passive response such as a message being silently displayed. Also note that the user doesn't have to validate the filter manually - it is done when OK is clicked as well, in which case it only creates a message box if there is a problem. That behaviour was modelled on the function editor in Crystal Reports. Whilst it's otherwise a UI nightmare, the validate button is pretty useful.> > And this is the only dialog that has a single non-standard sized button > on the left side... > Yes, to match those on the previous tab. When clicking between tabs, if those buttons were different sizes you would notice a 'jump'. As it is, the transition is smoother and more natural.> > seriously: View filtered Data. > Instead of showing a collapsed dialog, with data readily queried, the > expanded view without data is shown > That could work, though I still have reservations as the menu option doesn't immediately do what it describes, nor would it guide you to that goal in any way. As I see it that violates the principle of least astonishment... Regards, Dave.