Thread: Database designer

Just tried to use the database designer for some "real" work. Ran into
various problems:

1) The layout is basically broken on Mac OS X. See screenshot 1, which
shows very small fonts, and overlapping graphics which are nigh-on
impossible to use.

2) Why does it take so many steps to add a column? Click the + icon,
and choose a name, then right click and select a datatype
(incidentally, some common types like "text" require additional steps
to select from a dialogue, which still doesn't list things like array
types or use the proper names for aliased types we use elsewhere),
then right-click again if I need to add constraints, and right click
*again* if I then want to rename the constraint. This should all be
done using the existing "Add Column" dialogue. Similarly, the Tables
properties dialogue should probably also be used to edit entire
tables.

3) The column data type sub menu has a title which is inconsistent
with the rest of the application.

4) Columns and tables have "default" names when you create them, which
is inconsistent with the rest of the application.

5) At least one dialogue spells Cancel as CANCEL, which is
inconsistent with the rest of the application.

6) To modify a table I have to right-click it to get to the context
menu, but that only seems to work if the mouse is over a column name
(and only the text part - if the name is "a", I have to right-click
"a", not the space to the right of it, which may be above a longer
column name).

7) Why do we have to specify a short table name?

8) Why do I have to select a table before I can add a column to it for
the first time, but to modify it (except to add a relationship) I can
right-click and existing column? Seems partially related to 6).

9) The dialogue designs leave a lot to be desired. The new table
dialogue looks like it's pretending to be a Properties dialogue in
design, but isn't a standard size, whilst the new relationship
dialogue sometimes doesn't seem to render properly (see the second
screenshot), and sometimes renders properly but looks like it was
designed a 5:25PM on a Friday (see the third screenshot) and is very
far from intuitive.

10) The strings are in serious need of review. See the fourth
screenshot for example. I can help with this if needed.

11) Somehow, I managed to "minimise" a table, so that only the primary
key column is shown. I have no idea how. Clicking on what now looks
like a maximise icon that's appeared doesn't fix it (though the icon
does change to what looks like a minimise icon). The relationship
lines still render as if the table was the original size, even if I
move a table to force it to redraw.

12) The mouse pointer seems to change to different icons when moved
over certain elements of the drawing. This makes it very hard to see
what's going on and where to click (and is inconsistent with the rest
of the app where we don't do such things).

13) There is a "Preferences" menu. Why isn't the existing Option dialogue used?

14) Changing the font for the diagram objects only affects objects
added after the font is changed, not ones already on the diagram. It
does seem to improve 1) though (14pt lucida grande seems to more or
less fix the layout to the point it's usable, but it looks huge). See
the final screenshot.

All in all, I'm pretty disappointed. As it stands, this feature seems
to need a lot of work to get it to a standard that I'd be happy to see
in 1.16 :-(

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, 2012-03-01 at 14:44 +0000, Dave Page wrote:
> Just tried to use the database designer for some "real" work. Ran into
> various problems:
>
> 1) The layout is basically broken on Mac OS X. See screenshot 1, which
> shows very small fonts, and overlapping graphics which are nigh-on
> impossible to use.
>

I tried once on Mac OS X, and AFAIR, it was good. I probably need to try
again, and see what's wrong.

> 2) Why does it take so many steps to add a column? Click the + icon,
> and choose a name, then right click and select a datatype
> (incidentally, some common types like "text" require additional steps
> to select from a dialogue, which still doesn't list things like array
> types or use the proper names for aliased types we use elsewhere),
> then right-click again if I need to add constraints, and right click
> *again* if I then want to rename the constraint.

I agree it would be better to not have all of this. This is something I
want to work on, but didn't find the time yet. My main idea was to add a
properties widget to handle the properties of table (and columns).

>  This should all be
> done using the existing "Add Column" dialogue.

If you mean dlgColumn, I disagree. If you mean enhancing the current
dialog of DD, yeah why not. But I would rather much have a properties
widget to avoid the use of a dialog.

>  Similarly, the Tables
> properties dialogue should probably also be used to edit entire
> tables.
>

Not sure what you mean here.


> 3) The column data type sub menu has a title which is inconsistent
> with the rest of the application.
>

Quite easy to fix.

> 4) Columns and tables have "default" names when you create them, which
> is inconsistent with the rest of the application.
>

If the "rest of the application" is the browser, well, the DD is another
tool and may require any behaviour. But we can get rid of the
autonaming, I have no issue with that. BTW, we already use autonaming
for the autoindex of an FK.

> 5) At least one dialogue spells Cancel as CANCEL, which is
> inconsistent with the rest of the application.
>

Another one quite easy to fix.

> 6) To modify a table I have to right-click it to get to the context
> menu, but that only seems to work if the mouse is over a column name
> (and only the text part - if the name is "a", I have to right-click
> "a", not the space to the right of it, which may be above a longer
> column name).
>

Yes, this is something I want to change to allow right click every
where.

> 7) Why do we have to specify a short table name?
>

You're not required.

> 8) Why do I have to select a table before I can add a column to it for
> the first time, but to modify it (except to add a relationship) I can
> right-click and existing column? Seems partially related to 6).
>

Not sure why Luis did it that way. The advantage I see is that I don't
need to have multiple levels of dialogs.

> 9) The dialogue designs leave a lot to be desired.

Completely agree.

>  The new table
> dialogue looks like it's pretending to be a Properties dialogue in
> design, but isn't a standard size, whilst the new relationship
> dialogue sometimes doesn't seem to render properly (see the second
> screenshot), and sometimes renders properly but looks like it was
> designed a 5:25PM on a Friday (see the third screenshot) and is very
> far from intuitive.
>

Yes, I agree.

> 10) The strings are in serious need of review. See the fourth
> screenshot for example. I can help with this if needed.
>

Could use your help, of course.

> 11) Somehow, I managed to "minimise" a table, so that only the primary
> key column is shown. I have no idea how. Clicking on what now looks
> like a maximise icon that's appeared doesn't fix it (though the icon
> does change to what looks like a minimise icon). The relationship
> lines still render as if the table was the original size, even if I
> move a table to force it to redraw.
>

I didn't remember we could minimise/maximise tables, but seems a good
idea anyway. Need to fix the bug though.

> 12) The mouse pointer seems to change to different icons when moved
> over certain elements of the drawing. This makes it very hard to see
> what's going on and where to click (and is inconsistent with the rest
> of the app where we don't do such things).
>

Yes, I also want to get rid of this.

> 13) There is a "Preferences" menu. Why isn't the existing Option dialogue used?
>

Because it was easier for Luis to do it this way, and finish his project
on time. I failed to find time to fix this, even if it's something I
want to do.

> 14) Changing the font for the diagram objects only affects objects
> added after the font is changed, not ones already on the diagram. It
> does seem to improve 1) though (14pt lucida grande seems to more or
> less fix the layout to the point it's usable, but it looks huge). See
> the final screenshot.
>

That's another bug to fix.

> All in all, I'm pretty disappointed. As it stands, this feature seems
> to need a lot of work to get it to a standard that I'd be happy to see
> in 1.16 :-(
>

Yes, it still needs some work. Most of your complaints are valid, and
are known at least to me. I wanted to work on them earlier, but failed
to find the time to fix them. Anyway, most of them aren't difficult.

Kinda funny that, at the same time you sent your email, I had Luis on IM
telling me he wanted to continue his work on the database designer.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

Hi

On Thu, Mar 1, 2012 at 4:06 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:

>> 2) Why does it take so many steps to add a column? Click the + icon,
>> and choose a name, then right click and select a datatype
>> (incidentally, some common types like "text" require additional steps
>> to select from a dialogue, which still doesn't list things like array
>> types or use the proper names for aliased types we use elsewhere),
>> then right-click again if I need to add constraints, and right click
>> *again* if I then want to rename the constraint.
>
> I agree it would be better to not have all of this. This is something I
> want to work on, but didn't find the time yet. My main idea was to add a
> properties widget to handle the properties of table (and columns).

That's one idea. The main thing is to be able to edit everything in
one place without having to repeatedly right click to change a
different property.

>>  This should all be
>> done using the existing "Add Column" dialogue.
>
> If you mean dlgColumn, I disagree. If you mean enhancing the current
> dialog of DD, yeah why not. But I would rather much have a properties
> widget to avoid the use of a dialog.

I'd be OK with a suitable properties widget - certainly if we used the
dialogue some elements would need to be hidden/disabled... but, if we
use a dialogue to put everything in one place, it makes sense to use
the same design we already have as it aids user experience by
presenting them with a consistent, familiar interface.

>>  Similarly, the Tables
>> properties dialogue should probably also be used to edit entire
>> tables.
>>
>
> Not sure what you mean here.

To edit table-level stuff (name etc), we should also use the existing
dialogue. Or a properties pane. Again, for consistency.

>> 4) Columns and tables have "default" names when you create them, which
>> is inconsistent with the rest of the application.
>>
>
> If the "rest of the application" is the browser, well, the DD is another
> tool and may require any behaviour. But we can get rid of the
> autonaming, I have no issue with that. BTW, we already use autonaming
> for the autoindex of an FK.

DD is part of the same product, and should be consistent in design
with the rest of the product. I consider the autoindex name to be a
little different - a) it's something users normally won't want to
change, and b) it's based on the name they did enter themselves - it's
not a meaningless default.

>> 7) Why do we have to specify a short table name?
>>
>
> You're not required.

OK, let me rephrase. Why am I asked for one? What effect does it have
on the generated schema?

>> 8) Why do I have to select a table before I can add a column to it for
>> the first time, but to modify it (except to add a relationship) I can
>> right-click and existing column? Seems partially related to 6).
>>
>
> Not sure why Luis did it that way. The advantage I see is that I don't
> need to have multiple levels of dialogs.

I can't see that it would require any difference in dialogues. I'd
still need to name the column, but otherwise it just requires me to
add the first column in one way (by clicking the table), while
subsequent ones can be added in the same way, or by right clicking.
Why can't I just right-click for them all?

>> 11) Somehow, I managed to "minimise" a table, so that only the primary
>> key column is shown. I have no idea how. Clicking on what now looks
>> like a maximise icon that's appeared doesn't fix it (though the icon
>> does change to what looks like a minimise icon). The relationship
>> lines still render as if the table was the original size, even if I
>> move a table to force it to redraw.
>>
>
> I didn't remember we could minimise/maximise tables, but seems a good
> idea anyway. Need to fix the bug though.

It does seem reasonable, yes - especially for wide tables with lots of
columns. It should be more obvious how I did it though (or how to do
it).

>> 13) There is a "Preferences" menu. Why isn't the existing Option dialogue used?
>>
>
> Because it was easier for Luis to do it this way, and finish his project
> on time. I failed to find time to fix this, even if it's something I
> want to do.

Hmm, AKA: not ready to commit!

>> All in all, I'm pretty disappointed. As it stands, this feature seems
>> to need a lot of work to get it to a standard that I'd be happy to see
>> in 1.16 :-(
>>
>
> Yes, it still needs some work. Most of your complaints are valid, and
> are known at least to me. I wanted to work on them earlier, but failed
> to find the time to fix them. Anyway, most of them aren't difficult.

Good :-)

> Kinda funny that, at the same time you sent your email, I had Luis on IM
> telling me he wanted to continue his work on the database designer.

Also good - we need to get this sorted out prior to release to avoid
having to remove such a valuable feature.

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi

On Mon, Mar 5, 2012 at 3:29 PM, Luis Ochoa <ziul1979@gmail.com> wrote:
>
> Autonaming can be turn off, but the idea of adding this feature arises from
> good database design practices and the idea of having an initial default
> name for it, if the user don't want to use, just overwrite it and it
> automatically turn off.
> Just to clarify, What's the suggestion for it?

Remove the default, to match the behaviour elsewhere in the
application. You don't need to provide a default to require the user
to name the table - that can be required anyway (and would be, if the
user wants a usable script to be generated). Plus the current default
really doesn't meet good practices with PostgreSQL, as the default
name is mixed case.

>>> 7) Why do we have to specify a short table name?
>>>
>>
>> You're not required.
>
>> OK, let me rephrase. Why am I asked for one? What effect does it have
>> on the generated schema?
>
>
> Is for the use of autonaming feature. If that feature is turned off it
> shouldn't be need any more.

Auto naming of what?

> You can doit by two ways: minimize button and dragging table border (size
> icon) from the button. It sounds like a bug, normal behavior is just like a
> window with maximize/minimize buttons, I'm not sure about your problem, can
> you give me the steps to reproduce it, probably is a bug.

I can't find any way to resize using the mouse. I did get it to
minimise again, when I finally managed to click the _ icon instead of
+, but cannot get it to maximise again - all that happens is the
button icon changes.

> I really don't believe this feature should be removed, it should fixed I
> agree, but is a good designed feature, very flexible, able to do it things
> that other databases designer (even comercial ones) aren't able to do it.

Agreed - but just having has lots of cool features doesn't mean it's
ready to ship. There are a number of issues that I've identified, and
probably more I haven't found yet, and we won't ship a feature in
pgAdmin until we believe it's working to an appropriate standard -
that means bug free (with some allowance for low-impact issues that
cannot easily be resolved, and don't materially affect the user), with
a UI that's usable on all the supported platforms and is consistent
with the rest of the UX throughout the app, and is written in a way
that is maintainable moving forwards (the latter, not being an issue
in this case from what I've seen).

> I'll work on it but now I'm working and I'm able to use only my spare time
> to do it, but I'll make my best effort to finish in a professional way this
> feature. I'll start to work on some of your suggestions at the end of the
> week.

Thanks!

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, 2012-03-05 at 15:48 +0000, Dave Page wrote:
> Hi
>
> On Mon, Mar 5, 2012 at 3:29 PM, Luis Ochoa <ziul1979@gmail.com> wrote:
> >
> > Autonaming can be turn off, but the idea of adding this feature arises from
> > good database design practices and the idea of having an initial default
> > name for it, if the user don't want to use, just overwrite it and it
> > automatically turn off.
> > Just to clarify, What's the suggestion for it?
>
> Remove the default, to match the behaviour elsewhere in the
> application. You don't need to provide a default to require the user
> to name the table - that can be required anyway (and would be, if the
> user wants a usable script to be generated). Plus the current default
> really doesn't meet good practices with PostgreSQL, as the default
> name is mixed case.
>

I removed it yesterday evening.

> >>> 7) Why do we have to specify a short table name?
> >>>
> >>
> >> You're not required.
> >
> >> OK, let me rephrase. Why am I asked for one? What effect does it have
> >> on the generated schema?
> >
> >
> > Is for the use of autonaming feature. If that feature is turned off it
> > shouldn't be need any more.
>
> Auto naming of what?
>

FK, and index IIRC.

> > You can doit by two ways: minimize button and dragging table border (size
> > icon) from the button. It sounds like a bug, normal behavior is just like a
> > window with maximize/minimize buttons, I'm not sure about your problem, can
> > you give me the steps to reproduce it, probably is a bug.
>
> I can't find any way to resize using the mouse. I did get it to
> minimise again, when I finally managed to click the _ icon instead of
> +, but cannot get it to maximise again - all that happens is the
> button icon changes.
>

Yeah, it needs to be fixed with a better UI.

> > I really don't believe this feature should be removed, it should fixed I
> > agree, but is a good designed feature, very flexible, able to do it things
> > that other databases designer (even comercial ones) aren't able to do it.
>
> Agreed - but just having has lots of cool features doesn't mean it's
> ready to ship. There are a number of issues that I've identified, and
> probably more I haven't found yet, and we won't ship a feature in
> pgAdmin until we believe it's working to an appropriate standard -
> that means bug free (with some allowance for low-impact issues that
> cannot easily be resolved, and don't materially affect the user), with
> a UI that's usable on all the supported platforms and is consistent
> with the rest of the UX throughout the app, and is written in a way
> that is maintainable moving forwards (the latter, not being an issue
> in this case from what I've seen).
>

On such a huge patch, it's really hard to work without commiting some
parts of it. So I decided to commit each milestone of the project. I
agree with you that it lacks lots of tweaking, but it's not that bad.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On Thu, 2012-03-01 at 16:23 +0000, Dave Page wrote:
> Hi
>
> On Thu, Mar 1, 2012 at 4:06 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
> >> 2) Why does it take so many steps to add a column? Click the + icon,
> >> and choose a name, then right click and select a datatype
> >> (incidentally, some common types like "text" require additional steps
> >> to select from a dialogue, which still doesn't list things like array
> >> types or use the proper names for aliased types we use elsewhere),
> >> then right-click again if I need to add constraints, and right click
> >> *again* if I then want to rename the constraint.
> >
> > I agree it would be better to not have all of this. This is something I
> > want to work on, but didn't find the time yet. My main idea was to add a
> > properties widget to handle the properties of table (and columns).
>
> That's one idea. The main thing is to be able to edit everything in
> one place without having to repeatedly right click to change a
> different property.
>

There is no standard properties widget for 2.8. There is one available
with a wxWidgets licence, not sure I want to start working on adding it
to the pgadmin code. And 2.9 has this widget. Probably we'll start with
a simple dialog, better than the current one, and use the properties
widgets of 3.0 when it'll come out (their roadmap says summer 2012, but
it keeps getting postponed, and anyway, even if they do release it in
2012, it will be too late for 1.16).

> >>  This should all be
> >> done using the existing "Add Column" dialogue.
> >
> > If you mean dlgColumn, I disagree. If you mean enhancing the current
> > dialog of DD, yeah why not. But I would rather much have a properties
> > widget to avoid the use of a dialog.
>
> I'd be OK with a suitable properties widget - certainly if we used the
> dialogue some elements would need to be hidden/disabled... but, if we
> use a dialogue to put everything in one place, it makes sense to use
> the same design we already have as it aids user experience by
> presenting them with a consistent, familiar interface.
>
> >>  Similarly, the Tables
> >> properties dialogue should probably also be used to edit entire
> >> tables.
> >>
> >
> > Not sure what you mean here.
>
> To edit table-level stuff (name etc), we should also use the existing
> dialogue. Or a properties pane. Again, for consistency.
>

I understand your point of view. But using dlgTable and dlgColumn would
be kinda weird. All you can set in DD for a table is its name and
columns. We would have to disable so many widgets that I don't see the
point of doing this. The same applies to columns and constraints.

> >> 4) Columns and tables have "default" names when you create them, which
> >> is inconsistent with the rest of the application.
> >>
> >
> > If the "rest of the application" is the browser, well, the DD is another
> > tool and may require any behaviour. But we can get rid of the
> > autonaming, I have no issue with that. BTW, we already use autonaming
> > for the autoindex of an FK.
>
> DD is part of the same product, and should be consistent in design
> with the rest of the product. I consider the autoindex name to be a
> little different - a) it's something users normally won't want to
> change, and b) it's based on the name they did enter themselves - it's
> not a meaningless default.
>

It is a different tool with a different aim, mostly a graphical view of
a database. Such differences may force us to use different dialogs.

> >> 7) Why do we have to specify a short table name?
> >>
> >
> > You're not required.
>
> OK, let me rephrase. Why am I asked for one? What effect does it have
> on the generated schema?
>
> >> 8) Why do I have to select a table before I can add a column to it for
> >> the first time, but to modify it (except to add a relationship) I can
> >> right-click and existing column? Seems partially related to 6).
> >>
> >
> > Not sure why Luis did it that way. The advantage I see is that I don't
> > need to have multiple levels of dialogs.
>
> I can't see that it would require any difference in dialogues. I'd
> still need to name the column, but otherwise it just requires me to
> add the first column in one way (by clicking the table), while
> subsequent ones can be added in the same way, or by right clicking.
> Why can't I just right-click for them all?
>

Well, as I already said, you only have name and columns for table. In
DD, you cannot set its owner, its schema, its tablespace, its fillfactor
and so on. If we had to use the dlgTable dialog, we would have to
disable six tabs, and hide the SQL tab (which doesn't mean anything in
this context). We would have to disable some of the widgets in the first
tab, we would have to allow only the creation of primary key and foreign
key (no check and exclude constraint). Not sure such a big dialog with
only that few widgets would be such a great idea.

On dlgColumn, we would need to disable three tabs and hide the SQL tab.
We would also need to disable many widgets on the first and second tabs.
A bigger issue is the type combobox. Right now, we only allow to fire DD
with a connection to a database. But I think many people will like to be
able to use it without having an established connection. One reason
would be that it would help them to be sure they don't really change
their database. So, we'll have to allow its use without a connection to
a database. In that specific case, how will we handle the setting of a
column's type? My first idea was to use a simple textbox where a user
can enter anything he wants. But it can make things harder. How will we
handle issues like "this-type-doesn't-exist-in-my-database"? do we
really have to care about that? I have no good answer to that yet.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
> On such a huge patch, it's really hard to work without commiting some
> parts of it. So I decided to commit each milestone of the project. I
> agree with you that it lacks lots of tweaking, but it's not that bad.

There are numerous basic issues (such as dialog design, and even
labelling text) which most certainly should have been resolved prior
to commit - they are a matter of maintaining basic standards - and
that's not to mention that it's more or less impossible to use as
designed on at least Mac. To quote a French friend of mine from June
last year: "And without usability, it can't be commited in the pgadmin
repository."

I'll also give a gentle reminder that the two main changes I asked for
months back (and were told would be done) have not been completed yet
- dialogues rendered in XRC (partially complete, from what I can see),
and docs.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mar 6, 2012 9:23 AM, "Dave Page" <dpage@pgadmin.org> wrote:
>
> On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> >
> > On such a huge patch, it's really hard to work without commiting some
> > parts of it. So I decided to commit each milestone of the project. I
> > agree with you that it lacks lots of tweaking, but it's not that bad.
>
> There are numerous basic issues (such as dialog design, and even
> labelling text) which most certainly should have been resolved prior
> to commit - they are a matter of maintaining basic standards - and
> that's not to mention that it's more or less impossible to use as
> designed on at least Mac. To quote a French friend of mine from June
> last year: "And without usability, it can't be commited in the pgadmin
> repository."

Meh, who cares about mac? ;)

On a serious note, perhaps this patch was/is big enough that it would've warranted an actual development branch in the main repo to allow for easier testing and merging by more people while it progresses? It won't magically solve any problems of course, but it might be worth reconsidering the "branching policy" now that we've used git for a while and people are more used to it?

/Magnus

On Tue, 2012-03-06 at 09:32 +0100, Magnus Hagander wrote:
>
> On Mar 6, 2012 9:23 AM, "Dave Page" <dpage@pgadmin.org> wrote:
> >
> > On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
> > <guillaume@lelarge.info> wrote:
> > >
> > > On such a huge patch, it's really hard to work without commiting
> some
> > > parts of it. So I decided to commit each milestone of the project.
> I
> > > agree with you that it lacks lots of tweaking, but it's not that
> bad.
> >
> > There are numerous basic issues (such as dialog design, and even
> > labelling text) which most certainly should have been resolved prior
> > to commit - they are a matter of maintaining basic standards - and
> > that's not to mention that it's more or less impossible to use as
> > designed on at least Mac. To quote a French friend of mine from June
> > last year: "And without usability, it can't be commited in the
> pgadmin
> > repository."
>
> Meh, who cares about mac? ;)
>
> On a serious note, perhaps this patch was/is big enough that it
> would've warranted an actual development branch in the main repo to
> allow for easier testing and merging by more people while it
> progresses? It won't magically solve any problems of course, but it
> might be worth reconsidering the "branching policy" now that we've
> used git for a while and people are more used to it?
>

I would be fine with it if we had people to actually test it. But we
don't. Dave's complaining now but the feature is in since early
september 2011, meaning he didn't test it before. And the only one I
know testing it is Colin Beckingham, with a few interesting comments in
late february. Having a test branch won't resolve anything. Actually,
putting it in a test branch is probably the best way to forget about it.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On Tue, Mar 6, 2012 at 09:52, Guillaume Lelarge <guillaume@lelarge.info> wrote:
> On Tue, 2012-03-06 at 09:32 +0100, Magnus Hagander wrote:
>>
>> On Mar 6, 2012 9:23 AM, "Dave Page" <dpage@pgadmin.org> wrote:
>> >
>> > On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
>> > <guillaume@lelarge.info> wrote:
>> > >
>> > > On such a huge patch, it's really hard to work without commiting
>> some
>> > > parts of it. So I decided to commit each milestone of the project.
>> I
>> > > agree with you that it lacks lots of tweaking, but it's not that
>> bad.
>> >
>> > There are numerous basic issues (such as dialog design, and even
>> > labelling text) which most certainly should have been resolved prior
>> > to commit - they are a matter of maintaining basic standards - and
>> > that's not to mention that it's more or less impossible to use as
>> > designed on at least Mac. To quote a French friend of mine from June
>> > last year: "And without usability, it can't be commited in the
>> pgadmin
>> > repository."
>>
>> Meh, who cares about mac? ;)
>>
>> On a serious note, perhaps this patch was/is big enough that it
>> would've warranted an actual development branch in the main repo to
>> allow for easier testing and merging by more people while it
>> progresses? It won't magically solve any problems of course, but it
>> might be worth reconsidering the "branching policy" now that we've
>> used git for a while and people are more used to it?
>>
>
> I would be fine with it if we had people to actually test it. But we
> don't. Dave's complaining now but the feature is in since early
> september 2011, meaning he didn't test it before. And the only one I
> know testing it is Colin Beckingham, with a few interesting comments in
> late february. Having a test branch won't resolve anything. Actually,
> putting it in a test branch is probably the best way to forget about it.

I meant during development. You said "commit at each milestone" -
those commits could be on the dev branch, and then merged in when all
are done.

But yeah, as I said it won't magically solve any problems. If the
problem is lack of testers, then in theory making it slightly easier
to test might encourage more testing. But I doubt it's going to make a
big difference there...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Mar 6, 2012 at 8:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> On Mar 6, 2012 9:23 AM, "Dave Page" <dpage@pgadmin.org> wrote:
>>
>> On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>> >
>> > On such a huge patch, it's really hard to work without commiting some
>> > parts of it. So I decided to commit each milestone of the project. I
>> > agree with you that it lacks lots of tweaking, but it's not that bad.
>>
>> There are numerous basic issues (such as dialog design, and even
>> labelling text) which most certainly should have been resolved prior
>> to commit - they are a matter of maintaining basic standards - and
>> that's not to mention that it's more or less impossible to use as
>> designed on at least Mac. To quote a French friend of mine from June
>> last year: "And without usability, it can't be commited in the pgadmin
>> repository."
>
> Meh, who cares about mac? ;)
>
> On a serious note, perhaps this patch was/is big enough that it would've
> warranted an actual development branch in the main repo to allow for easier
> testing and merging by more people while it progresses? It won't magically
> solve any problems of course, but it might be worth reconsidering the
> "branching policy" now that we've used git for a while and people are more
> used to it?

Yeah, that was one of the suggestions I was going to make in my last
email, but scrubbed it as I was already worried it was sounding a
little harsh (though, I believe my points were all valid).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Mar 6, 2012 at 8:52 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> On Tue, 2012-03-06 at 09:32 +0100, Magnus Hagander wrote:
>>
>> On Mar 6, 2012 9:23 AM, "Dave Page" <dpage@pgadmin.org> wrote:
>> >
>> > On Tue, Mar 6, 2012 at 8:01 AM, Guillaume Lelarge
>> > <guillaume@lelarge.info> wrote:
>> > >
>> > > On such a huge patch, it's really hard to work without commiting
>> some
>> > > parts of it. So I decided to commit each milestone of the project.
>> I
>> > > agree with you that it lacks lots of tweaking, but it's not that
>> bad.
>> >
>> > There are numerous basic issues (such as dialog design, and even
>> > labelling text) which most certainly should have been resolved prior
>> > to commit - they are a matter of maintaining basic standards - and
>> > that's not to mention that it's more or less impossible to use as
>> > designed on at least Mac. To quote a French friend of mine from June
>> > last year: "And without usability, it can't be commited in the
>> pgadmin
>> > repository."
>>
>> Meh, who cares about mac? ;)
>>
>> On a serious note, perhaps this patch was/is big enough that it
>> would've warranted an actual development branch in the main repo to
>> allow for easier testing and merging by more people while it
>> progresses? It won't magically solve any problems of course, but it
>> might be worth reconsidering the "branching policy" now that we've
>> used git for a while and people are more used to it?
>>
>
> I would be fine with it if we had people to actually test it. But we
> don't. Dave's complaining now but the feature is in since early
> september 2011, meaning he didn't test it before.

Right - but I said at the time I didn't have the cycles to do any
testing, and you said you were going to test on Mac, which I said I
was happy with.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, 2012-03-06 at 09:20 +0100, Guillaume Lelarge wrote:
> On Thu, 2012-03-01 at 16:23 +0000, Dave Page wrote:
> > Hi
> >
> > On Thu, Mar 1, 2012 at 4:06 PM, Guillaume Lelarge
> > <guillaume@lelarge.info> wrote:
> >
> > >> 2) Why does it take so many steps to add a column? Click the + icon,
> > >> and choose a name, then right click and select a datatype
> > >> (incidentally, some common types like "text" require additional steps
> > >> to select from a dialogue, which still doesn't list things like array
> > >> types or use the proper names for aliased types we use elsewhere),
> > >> then right-click again if I need to add constraints, and right click
> > >> *again* if I then want to rename the constraint.
> > >
> > > I agree it would be better to not have all of this. This is something I
> > > want to work on, but didn't find the time yet. My main idea was to add a
> > > properties widget to handle the properties of table (and columns).
> >
> > That's one idea. The main thing is to be able to edit everything in
> > one place without having to repeatedly right click to change a
> > different property.
> >
>
> There is no standard properties widget for 2.8. There is one available
> with a wxWidgets licence, not sure I want to start working on adding it
> to the pgadmin code. And 2.9 has this widget. Probably we'll start with
> a simple dialog, better than the current one, and use the properties
> widgets of 3.0 when it'll come out (their roadmap says summer 2012, but
> it keeps getting postponed, and anyway, even if they do release it in
> 2012, it will be too late for 1.16).
>

I've been thinking about this. I don't like the idea of displaying a
dialog. I've been doing some experiments on panels, and this is what I
have now. Not pretty, but not done yet. Just an idea of how it might
look like and work. See screenshot attached. Each time you select a
table, this panel is refreshed with the informations from the table. You
can modify the table informations with this panel. I'm wondering if I
should add a OK button. Anyway.

If it seems good to you, then I'll work on this, and propose a patch.
(meaning I'm waiting for an answer before going any further)


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On Tue, Mar 20, 2012 at 10:40 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
> I've been thinking about this. I don't like the idea of displaying a
> dialog. I've been doing some experiments on panels, and this is what I
> have now. Not pretty, but not done yet. Just an idea of how it might
> look like and work. See screenshot attached. Each time you select a
> table, this panel is refreshed with the informations from the table. You
> can modify the table informations with this panel. I'm wondering if I
> should add a OK button. Anyway.

Maybe an "Apply" button? Otherwise, it looks promising. I'd continue.

Thanks!

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, 2012-03-21 at 09:55 +0000, Dave Page wrote:
> On Tue, Mar 20, 2012 at 10:40 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> >
> > I've been thinking about this. I don't like the idea of displaying a
> > dialog. I've been doing some experiments on panels, and this is what I
> > have now. Not pretty, but not done yet. Just an idea of how it might
> > look like and work. See screenshot attached. Each time you select a
> > table, this panel is refreshed with the informations from the table. You
> > can modify the table informations with this panel. I'm wondering if I
> > should add a OK button. Anyway.
>
> Maybe an "Apply" button? Otherwise, it looks promising. I'd continue.
>

"Apply" is great. That's the word I was looking for. Thanks.

Work in progress. See new screenshot attached.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On Wed, Mar 21, 2012 at 10:23 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> On Wed, 2012-03-21 at 09:55 +0000, Dave Page wrote:
>> On Tue, Mar 20, 2012 at 10:40 PM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>> >
>> > I've been thinking about this. I don't like the idea of displaying a
>> > dialog. I've been doing some experiments on panels, and this is what I
>> > have now. Not pretty, but not done yet. Just an idea of how it might
>> > look like and work. See screenshot attached. Each time you select a
>> > table, this panel is refreshed with the informations from the table. You
>> > can modify the table informations with this panel. I'm wondering if I
>> > should add a OK button. Anyway.
>>
>> Maybe an "Apply" button? Otherwise, it looks promising. I'd continue.
>>
>
> "Apply" is great. That's the word I was looking for. Thanks.
>
> Work in progress. See new screenshot attached.

Getting there :-). Obviously still some border spacing issues, and I'm
not sure I like the layout of the buttons. Not sure I see a better way
of doing it that wouldn't look odd though.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, 2012-03-22 at 09:12 +0000, Dave Page wrote:
> On Wed, Mar 21, 2012 at 10:23 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> > On Wed, 2012-03-21 at 09:55 +0000, Dave Page wrote:
> >> On Tue, Mar 20, 2012 at 10:40 PM, Guillaume Lelarge
> >> <guillaume@lelarge.info> wrote:
> >> >
> >> > I've been thinking about this. I don't like the idea of displaying a
> >> > dialog. I've been doing some experiments on panels, and this is what I
> >> > have now. Not pretty, but not done yet. Just an idea of how it might
> >> > look like and work. See screenshot attached. Each time you select a
> >> > table, this panel is refreshed with the informations from the table. You
> >> > can modify the table informations with this panel. I'm wondering if I
> >> > should add a OK button. Anyway.
> >>
> >> Maybe an "Apply" button? Otherwise, it looks promising. I'd continue.
> >>
> >
> > "Apply" is great. That's the word I was looking for. Thanks.
> >
> > Work in progress. See new screenshot attached.
>
> Getting there :-). Obviously still some border spacing issues, and I'm
> not sure I like the layout of the buttons. Not sure I see a better way
> of doing it that wouldn't look odd though.
>

I've made some progress on this. Here are two new screenshots showing
the new properties panel with a notebook.

I hope to finish it tomorrow.


--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com