Re: Database designer - Mailing list pgadmin-hackers

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