Thread: Suggestions for the next version
A couple of UI-suggestions for the next version of pgadminIII. I believe pgadmin could benefit from a tighter integration between the view data tool and the main window. 1. Make the tabs in the right pane refer to the whole right pane, not just the upper part, and let the DDL-vindow be part of the Properties-tab, or move it to a separate 'Definition' tab, or into a general SQL-tab. 2. Add a 'View' tab to the pane, essentially an in-place version of the 'view data' window. This makes it much more easy to browse through many tables. I also think it would be nice to have a SQL-tab in the right pane, and moving the Query Tool into this pane instead of having it in a separate window. However, I'm not really sure whether that is just because I'm used to Borlands's SQL Explorer or because it really is a good idea. -- Brage Førland
Brage Førland wrote: >A couple of UI-suggestions for the next version of pgadminIII. > >I believe pgadmin could benefit from a tighter integration between the view >data tool and the main window. > >1. Make the tabs in the right pane refer to the whole right pane, not just > the upper part, and let the DDL-vindow be part of the Properties-tab, or > move it to a separate 'Definition' tab, or into a general SQL-tab. > >2. Add a 'View' tab to the pane, essentially an in-place version of the 'view > data' window. This makes it much more easy to browse through many tables. > >I also think it would be nice to have a SQL-tab in the right pane, and >moving the Query Tool into this pane instead of having it in a separate >window. However, I'm not really sure whether that is just because I'm used >to Borlands's SQL Explorer or because it really is a good idea. > > > Hm, don't really like that. Putting the DataView in the lower right corner has several disadvantages: it's small and for worse it's slowing down object browsing, which contradicts the intention. The Query Tool doesn't belong logically into that corner, actually it can be regarded separated from the browsing tree at all (and it needs its separate menu). So I think it's best the way it is now, and Borland just tried to marry everything into one window, if it belongs together or not. Regards, Andreas
On Tue, Jul 29, 2003 at 07:44:03PM +0200, Andreas Pflug wrote: > Brage Førland wrote: > > > > >2. Add a 'View' tab to the pane, essentially an in-place version of the > >'view > > data' window. This makes it much more easy to browse through many > > tables. > Hm, don't really like that. Putting the DataView in the lower right > corner has several disadvantages: it's small and for worse it's slowing > down object browsing, which contradicts the intention. A data view in the right pane could be in addtion to the larger window you get if you choose 'view data' from the context menu. It wouldn't be that small if the right pane wasn't divided in two sections. It also should not have any impact on performance unless the user has the view data-pane in focus. > The Query Tool > doesn't belong logically into that corner, actually it can be regarded > separated from the browsing tree at all (and it needs its separate > menu). So I think it's best the way it is now, and Borland just tried to > marry everything into one window, if it belongs together or not. An in-place SQL-tool would make sense for the DDL. If you choose av view, select the SQL-tab, you'd get the DDL for the view, which you might edit and run. Beeing able to run an arbitary SQL query in the window would just be a bonus. -- Brage Førland
Brage Førland wrote: >On Tue, Jul 29, 2003 at 07:44:03PM +0200, Andreas Pflug wrote: > > >>Brage Førland wrote: >> >> >> >>> >>>2. Add a 'View' tab to the pane, essentially an in-place version of the >>>'view >>> data' window. This makes it much more easy to browse through many >>> tables. >>> >>> > > > >>Hm, don't really like that. Putting the DataView in the lower right >>corner has several disadvantages: it's small and for worse it's slowing >>down object browsing, which contradicts the intention. >> >> > >A data view in the right pane could be in addtion to the larger window you >get if you choose 'view data' from the context menu. It wouldn't be that >small if the right pane wasn't divided in two sections. It also should not >have any impact on performance unless the user has the view data-pane in >focus. > > That would make the DataView longer, but not wider. If you have only tables with <5 columns, that might be ok.... And would increase complexity (and usability) concerning menu handling. >> The Query Tool >>doesn't belong logically into that corner, actually it can be regarded >>separated from the browsing tree at all (and it needs its separate >>menu). So I think it's best the way it is now, and Borland just tried to >>marry everything into one window, if it belongs together or not. >> >> > >An in-place SQL-tool would make sense for the DDL. If you choose av view, >select the SQL-tab, you'd get the DDL for the view, which you might edit and >run. Beeing able to run an arbitary SQL query in the window would just be a >bonus. > Why should you run the reverse-engineered SQL? It reflects (partially) what's already present in the database! It's suggested as a starting point or template to make some more complicated changes. And they could be quite dangerous too! Additionally, as with the View Data, we get menu handling problems. What's the meaning of F5? Currently, on the main window, it's refresh, and in the query tool it's the sql version of it, execute. So what is F5 supposed to be if windows are mangled together? No, I the longer we're discussing this, the less I like it. Regards, Andreas
On Wed, Jul 30, 2003 at 12:01:44AM +0200, Andreas Pflug wrote: > Brage Førland wrote: > > >On Tue, Jul 29, 2003 at 07:44:03PM +0200, Andreas Pflug wrote: > >A data view in the right pane could be in addtion to the larger window you > >get if you choose 'view data' from the context menu. It wouldn't be that > >small if the right pane wasn't divided in two sections. It also should not > >have any impact on performance unless the user has the view data-pane in > >focus. > > > > > That would make the DataView longer, but not wider. If you have only > tables with <5 columns, that might be ok.... And would increase > complexity (and usability) concerning menu handling. I still think there should be a one-click-way to browse the content of the tables. While pgadmin is a very good tool for database administration, I believe making the content of the database more accessible would make it a better tool for database development. > Why should you run the reverse-engineered SQL? It reflects (partially) > what's already present in the database! It's suggested as a starting > point or template to make some more complicated changes. And they could > be quite dangerous too! This is what you get currently if you select the QueryTool. -- Brage Førland
Brage Førland wrote: > > > >>Why should you run the reverse-engineered SQL? It reflects (partially) >>what's already present in the database! It's suggested as a starting >>point or template to make some more complicated changes. And they could >>be quite dangerous too! >> >> > >This is what you get currently if you select the QueryTool. > > Brage, there's still no solution for the two complete separate sets of menu items which would be needed. I'm not a fan of exchanging the menu case by case, because this can be irritating, and wxWindows showed some trouble with exchanging menus too. And again: it's a bit dangerous, because F5 is dual-used, you could trigger something you don't really intended in the current context. Regards, Andreas