Re: GSoC database modeler [Luis Ochoa]

On Tue, Aug 24, 2010 at 4:33 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info>wrote:

> Le 17/08/2010 04:44, Luis Ochoa a écrit :
> > On Mon, Aug 16, 2010 at 5:26 PM, Guillaume Lelarge
> > <guillaume(at)lelarge(dot)info>wrote:
> > [...]
> >> I think we need to get rid of the "undefined" pseudo-type. I would like
> >> to change the "Add column" menu item to show a dialog with a text box to
> >> enter the name of the column and a combobox to choose the type (and
> >> precision too in case of varchar and numeric type).
> >>
> >
> > I believe it too "undefined" should go away, and we can use a default
> > datatype for column if user wants to change just select another...
> >
>
> Having a default datatype will be a burden. Which one should we choose,
> and why? and I'm sure lots of people will complain it's not their
> prefered datatype.
>

I can be setting that user would change if he like it.

> > Add column at table can bring a dialog, I think to do that but for time
> > reasons I didn't do it.
> >
>
> Will do.
>

Something like a property dialog that you sent me before it would be great.

>
> >> > I still think one thing which definitely needs changing are the
> >>> controls. Most of them cover a very small pixel area and as such make
> >>> it tricky to click on and prone to missing them (or at least it would
> >>> be for me).
> >>
> > It is just a initial UI design it can be changed, but you always have
> two
> > options to do that:
> >
> > fast-> graphically
> > normal->contextual menus
> >
>
> Fast, graphically? you must be kidding :) the icon area is so small I
> have a real hard time to use it.
>
>> Well, I also think we should get rid of them. Every action should start
> >> within the contextual menu. No Add or Delete button. And I don't really
> >> like the "double click" to rename an object. We should use the
> >> contextual menu once again
> >>
> >
> > I really don't support this idea, because I use modelers all the time and
> > the main idea of why I like to create a new one was:
> >
> > I like to do modeling as fast as I can, but bringing a window for every
> > action puts everything slower (with little changes when modeling), but
> when
> > you are entering columns at first time I believe a dialog with grid style
> > will be better (I thought to do that but for time reasons again)
> >
> > My idea is two ways of entering data to models: graphically & using
> > properties like dialogs, people must choice what to use in what moment.
> >
>
> I wasn't saying to use the properties dialog we have. I wanted to say we
> should simply have a dialog with one or two controls (name, or name and
> datatype). With a dialog with a simple name to type, it's as quick as
> what you have, and much more usable (click enter and it validates your
> typing, click esc and it cancels your typing, buttons are more easy to
> click, UI is way more visible and understandable).
>

Altering way of fast editing (double click on column) with somekind of new
dialog is a good choice but main problem and explanation about what I do is
that dd/draw folder was written in a generic way, and we shouldn't alter it
to our designer, instead we should derivate a new class from
ddDrawingView.cpp that allow to do all that new dialog for editing. I was
thinking on do that, but at that time I don't have enough time for it, I'm
going to do this at next few days.

> > > Although I appreciate you're still in the middle of
> >>> working on everything and are just working on functionality rather
> >>> than presentation.
> >>
> >> Actually, it's the end of the GSoC. I think Luis still wants to work on
> >> it, and I really hope so.
> >>
> >>
> > UI is just for showing base classes for drawing and modeling working, not
> a
> > real window for modeler, it should be changed :D
> >
>
> I did quite some work on it. Mostly to understand your code. But also to
> make a few changes. All warnings are fixed on my repo. I also did some
> indentation enhancements. And I reworked the UI: no wxSplitterWindow,
> use of two panes (one for the designer, one for the sql text), change
> the rename of the table, etc.
>

Main graphic engine is based on hotdraw if you can find docs about it maybe
help you to understand it in an easier way.

UI at GSoC was terrible just works like a container to test framework and
database designer classes, it must be changed to a better one :D

>
> Everyt thing is here: http://github.com/gleu/pgadmin3/commits/ticket225
>
> >> > Also, could the play button (which currently shows the SQL) just say
> >>> "SQL" on it?
> >>
> >> Yes, that would be best. The "play" button is the execute button on the
> >> Query Tool. Quite confusing.
> >>
> >>> And for it to appear in a separate panel in the same window?
> >>
> >
> > This is really a sandbox for modeler, just like a test of base classes of
> > the modeler and graphical library, because this gsoc project created two
> > things:
> >
> > - A graphical framework for doing modeler and drawing like applications.
> > -The modeler using the generic framework for graphics.
> >
> > Real one UI should come later.
> >
>
> Yeah, I'm working on it.
>
> >> We'll probably have to get rid of the notebook and have two panes, one
> >> to draw the schema, one to see the SQL. They can both have a toolbar. On
> >> the draw pane, we could have load, save, sql buttons. On the SQL pane,
> >> we could have save, run, open query tool.
> >>
> >>
> > My idea is one pane for every model, we can open one or more at same
> time.
> > SQL can be show in other way...
> >
>
> Too much work for now. I keep the notebook with only one page. The
> multi-pages can be done in another patch.
>
> >> > Sort of like results currently do for the SQL Query Editor in
> >>> PgAdmin. In fact, maybe if the pane is open and you make changes to
> >>> the diagram, it could update the pane contents in real time?
> >>>
> >>
> >>
> > Just a test, that notepad is just to show results and must be changed at
> > real one ;)
> >
> >> Yeah, could be possible.
> >>
> >> The last item we should not forget is a reverse engineer button. I've
> >> read some parts of the code Luis wrote, and I think it should be pretty
> >> easy to do. AFAICT, it's a one day job, considering all the foundations
> >> built by Luis.
> >>
> >>
> > It shouldn't be harder to do it, but there is a lot of things and bugs to
> > fix before it can be profesionally used.
> >
>
> RE will be done in another patch. Right now, I'm trying to get something
> commitable. I feel there's more and more work to do on it before
> acheiving a commitable state.
>
>
I now what are you saying, is like a neverending coding... you finish
something and a new one bug/feature appears ;)

Regards, Luis.