Re: Function editor

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 11 October 2004 16:06
> To: Dave Page
> Cc: pgadmin-support(at)postgresql(dot)org
> Subject: Re: [pgadmin-support] Function editor
>
> Fortunately, hard hats not only prevent from damage caused by
> outer impacts :-)

I thought you ran Debian? Perhaps you should consider Fedora...

> When mentioning modal you're scratching the problem. Making
> the additional window modal would probably have more impact
> on other parts.

Oh, I realise that. Hence the call for discussion.

> In this case, it would be a frame (eventually covering the
> whole screen), being child of a dialog. This is probably not
> gonna work smoothly (pgadmin-wide modal). Modal dialogs mean
> "the developer didn't now how to handle the stuff better, so
> he locks the rest of the machine", reducing to single task
> programming.

Agreed - I'd rather avoid using anything modal, and I know if I tried
I'd have another fight with you about it :-)

> All apps that offered such kind of editing facility I can
> remember drove me nuts (VB 'zoom', SyBase AppModeler too). I
> do see the necessity to have much space available for
> editing, but I'd expect that in practice extended
> functions/views aren't edited using the property dialogs, but
> with the query tool instead to have the code saveable into a
> file any time, including the test code used for developing
> it.

That's kinda heading off in the direction I think Jean-Michel was tryng
to take pga1 when he experimented with an Oracle like Packages system.
It would require far more thought and redesign to make it natural to
/not/ use the prop dialogues.

My thoughts on a GUI editor are less complex. There's no reason it
couldn't have a Save button, or a Save Definition button that saved not
just what you were editting, but the entire SQL query that would be run.

> Using the property dialogs is a bit like fixing your app
> by applying patched bytes at runtime instead of modifying
> your sources and recompiling.

Yes, but without having a full blown package system, there's not much
else we can do.

> Redesigning dlgFunction/dlgView to be nonsizeable and have
> the Zoom button would probable make these dialog look nicer,
> but make them quite unusable too (unless Zoom is pressed; did
> I mention I hate the M$ epidemic use of windows layering one
> atop another?).

Depends what you're doing. I don't often resize them myself, but then my
usage patterns don't necessarily match other ppls.

Incidently, wrt the other solution of converting all dialogues to be
wxFrame based, assuming it works you should be able to set
wxFRAME_NO_TASKBAR to prevent the taskbar icons showing up. Not sure
what other effects that would have, but it probably would then need some
dialogue refactoring to include sizers on everything.

Regards, Dave.