Thread: Info on non supported Features
Hi Guys,
as I started working on email notification Dave told me, that I've to disable all email notification relevant GUI elements, if the required pgAgent version is not installed.
I did that of course, but I thought why we should not tell the user, why a control is disabled.
My idea is not to disable the control, but hide it and place an explaining text on it's position. In code we know which version is required because of the call pgConn::BackendMinimumVersion(major, minor).
I've extended this method to pgConn::BackendMinimumVersion(major,wxControl* control) and every time this is called, the desired control will be hidden and a wxStaticText control will be added.
The text is for example: Supported in PostgreSQL %i.%i, major, minor => Supported in PostgreSQL 9.1. See also the attached screenshots.
I know this is not applicable in all situations, but it's a useful information.
What you think about it? Shall I finalize this feature?
Jasmin
Attachment
Hi, Le 10/01/2011 02:22, Jasmin Dizdarevic a écrit : > [...] > as I started working on email notification Dave told me, that I've to > disable all email notification relevant GUI elements, if the required > pgAgent version is not installed. > I did that of course, but I thought why we should not tell the user, why a > control is disabled. > > My idea is not to disable the control, but hide it and place an explaining > text on it's position. In code we know which version is required because of > the call pgConn::BackendMinimumVersion(major, minor). > I've extended this method to pgConn::BackendMinimumVersion(major,wxControl* > control) and every time this is called, the desired control will be hidden > and a wxStaticText control will be added. > > The text is for example: Supported in PostgreSQL %i.%i, major, minor > => Supported in PostgreSQL 9.1. See also the attached screenshots. > > I know this is not applicable in all situations, but it's a useful > information. > > What you think about it? Shall I finalize this feature? > The idea is interesting. I wonder if it works well with resizable dialogs. Did you try? -- Guillaume http://www.postgresql.fr http://dalibo.com
On Mon, Jan 10, 2011 at 1:22 AM, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > Hi Guys, > as I started working on email notification Dave told me, that I've to > disable all email notification relevant GUI elements, if the required > pgAgent version is not installed. > I did that of course, but I thought why we should not tell the user, why a > control is disabled. > My idea is not to disable the control, but hide it and place an explaining > text on it's position. In code we know which version is required because of > the call pgConn::BackendMinimumVersion(major, minor). > I've extended this method to pgConn::BackendMinimumVersion(major,wxControl* > control) and every time this is called, the desired control will be hidden > and a wxStaticText control will be added. > The text is for example: Supported in PostgreSQL %i.%i, major, minor > => Supported in PostgreSQL 9.1. See also the attached screenshots. > I know this is not applicable in all situations, but it's a useful > information. > What you think about it? Shall I finalize this feature? Changing the type of control doesn't seem like a good idea. It can make the dialogue look different depending on the server that is connected, which may confuse the user. If you simply set the text in the existing control, I think that would be acceptable. Of course, it wouldn't work for radio buttons/checkboxes, but I think that's a small price to pay. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 10/01/2011 10:53, Dave Page a écrit : > On Mon, Jan 10, 2011 at 1:22 AM, Jasmin Dizdarevic > <jasmin.dizdarevic@gmail.com> wrote: >> Hi Guys, >> as I started working on email notification Dave told me, that I've to >> disable all email notification relevant GUI elements, if the required >> pgAgent version is not installed. >> I did that of course, but I thought why we should not tell the user, why a >> control is disabled. >> My idea is not to disable the control, but hide it and place an explaining >> text on it's position. In code we know which version is required because of >> the call pgConn::BackendMinimumVersion(major, minor). >> I've extended this method to pgConn::BackendMinimumVersion(major,wxControl* >> control) and every time this is called, the desired control will be hidden >> and a wxStaticText control will be added. >> The text is for example: Supported in PostgreSQL %i.%i, major, minor >> => Supported in PostgreSQL 9.1. See also the attached screenshots. >> I know this is not applicable in all situations, but it's a useful >> information. >> What you think about it? Shall I finalize this feature? > > Changing the type of control doesn't seem like a good idea. It can > make the dialogue look different depending on the server that is > connected, which may confuse the user. If you simply set the text in > the existing control, I think that would be acceptable. Of course, it > wouldn't work for radio buttons/checkboxes, but I think that's a small > price to pay. > I don't see why it couldn't work for radio buttons and checkboxes. They also have text. We dont' use that now, but it could be use for this. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Mon, Jan 10, 2011 at 9:55 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > I don't see why it couldn't work for radio buttons and checkboxes. They > also have text. We dont' use that now, but it could be use for this. That's exactly why - consider 3 radio buttons in a row with labels between them; if you suddenly set the text to "Feature supported in Postgres 8.3 and later", you could end up with something looking like: Widget? ( ) Enabled Feature supported in Postgres 8.3 and later ( ) Disabled Feature supported in Postgres 8.3 and later ( ) Default Feature supported in Postgres 8.3 and later (all on one line). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Sure, it's possible, but then you have take care of each control individually. Setting a text in a combobx and checkbox is quiet different.
I think this change is acceptable, because the label control is kept. Only the control, which is also not accessible by a tab is hidden.
Radio buttons could not be covered this way. The items would have to be disabled manually.
Resizing should not be a problem (in my test there were no problems), because the control is replaced through wxSizer::Replace(). So it's kept in the "grid flow".
2011/1/10 Guillaume Lelarge <guillaume@lelarge.info>
Le 10/01/2011 10:53, Dave Page a écrit :I don't see why it couldn't work for radio buttons and checkboxes. They> On Mon, Jan 10, 2011 at 1:22 AM, Jasmin Dizdarevic
> <jasmin.dizdarevic@gmail.com> wrote:
>> Hi Guys,
>> as I started working on email notification Dave told me, that I've to
>> disable all email notification relevant GUI elements, if the required
>> pgAgent version is not installed.
>> I did that of course, but I thought why we should not tell the user, why a
>> control is disabled.
>> My idea is not to disable the control, but hide it and place an explaining
>> text on it's position. In code we know which version is required because of
>> the call pgConn::BackendMinimumVersion(major, minor).
>> I've extended this method to pgConn::BackendMinimumVersion(major,wxControl*
>> control) and every time this is called, the desired control will be hidden
>> and a wxStaticText control will be added.
>> The text is for example: Supported in PostgreSQL %i.%i, major, minor
>> => Supported in PostgreSQL 9.1. See also the attached screenshots.
>> I know this is not applicable in all situations, but it's a useful
>> information.
>> What you think about it? Shall I finalize this feature?
>
> Changing the type of control doesn't seem like a good idea. It can
> make the dialogue look different depending on the server that is
> connected, which may confuse the user. If you simply set the text in
> the existing control, I think that would be acceptable. Of course, it
> wouldn't work for radio buttons/checkboxes, but I think that's a small
> price to pay.
>
also have text. We dont' use that now, but it could be use for this.
Le 10/01/2011 11:01, Dave Page a écrit : > On Mon, Jan 10, 2011 at 9:55 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > >> I don't see why it couldn't work for radio buttons and checkboxes. They >> also have text. We dont' use that now, but it could be use for this. > > That's exactly why - consider 3 radio buttons in a row with labels > between them; if you suddenly set the text to "Feature supported in > Postgres 8.3 and later", you could end up with something looking like: > > Widget? ( ) Enabled Feature supported in Postgres 8.3 and later ( > ) Disabled Feature supported in Postgres 8.3 and later ( ) Default > Feature supported in Postgres 8.3 and later > > (all on one line). > OK, understood. That's an issue. -- Guillaume http://www.postgresql.fr http://dalibo.com
Le 10/01/2011 11:07, Jasmin Dizdarevic a écrit : > Sure, it's possible, but then you have take care of each control > individually. Setting a text in a combobx and checkbox is quiet different. > I think this change is acceptable, because the label control is kept. Only > the control, which is also not accessible by a tab is hidden. > > > Radio buttons could not be covered this way. The items would have to be > disabled manually. > > Resizing should not be a problem (in my test there were no problems), > because the control is replaced through wxSizer::Replace(). So it's kept in > the "grid flow". > "Resizing should not be a problem"... that's a good one :-D I hope you're right. But, from my experience, there's always something weird in resizing. -- Guillaume http://www.postgresql.fr http://dalibo.com
2011/1/10 Guillaume Lelarge <guillaume@lelarge.info>
Le 10/01/2011 11:07, Jasmin Dizdarevic a écrit :> Sure, it's possible, but then you have take care of each control"Resizing should not be a problem"... that's a good one :-D
> individually. Setting a text in a combobx and checkbox is quiet different.
> I think this change is acceptable, because the label control is kept. Only
> the control, which is also not accessible by a tab is hidden.
>
>
> Radio buttons could not be covered this way. The items would have to be
> disabled manually.
>
> Resizing should not be a problem (in my test there were no problems),
> because the control is replaced through wxSizer::Replace(). So it's kept in
> the "grid flow".
>
Have you ever had problems with it? ;-)
I hope you're right. But, from my experience, there's always something
weird in resizing.
As I can see and can understand what you mean - there are really no issues, I've just replaces a comment field that grows with the window and there are no issues. Also overloading the textfield with text (> 150 signs) works perfect.
--
Le 10/01/2011 11:31, Jasmin Dizdarevic a écrit : > 2011/1/10 Guillaume Lelarge <guillaume@lelarge.info> > >> Le 10/01/2011 11:07, Jasmin Dizdarevic a écrit : >>> Sure, it's possible, but then you have take care of each control >>> individually. Setting a text in a combobx and checkbox is quiet >> different. >>> I think this change is acceptable, because the label control is kept. >> Only >>> the control, which is also not accessible by a tab is hidden. >>> >>> >>> Radio buttons could not be covered this way. The items would have to be >>> disabled manually. >>> >>> Resizing should not be a problem (in my test there were no problems), >>> because the control is replaced through wxSizer::Replace(). So it's kept >> in >>> the "grid flow". >>> >> >> "Resizing should not be a problem"... that's a good one :-D >> > > Have you ever had problems with it? ;-) > >> >> I hope you're right. But, from my experience, there's always something >> weird in resizing. >> > > As I can see and can understand what you mean - there are really no issues, > I've just replaces a comment field that grows with the window and there are > no issues. Also overloading the textfield with text (> 150 signs) works > perfect. > Good for you. Did you check on every dialog? do you have a patch to send to us? and a branch on your git that I can get a look at? -- Guillaume http://www.postgresql.fr http://dalibo.com
---------- Forwarded message ----------
From: Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>
Date: 2011/1/10
Subject: Re: [pgadmin-hackers] Info on non supported Features
To: Guillaume Lelarge <guillaume@lelarge.info>
Hi,
From: Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>
Date: 2011/1/10
Subject: Re: [pgadmin-hackers] Info on non supported Features
To: Guillaume Lelarge <guillaume@lelarge.info>
Hi,
you will need this two patches - i hope it works.
I'm interested, how you would take a look on a branch of mine. This would make things a lot easier at all?
I've tested three dialogs until now. dlgDatabase, dlgTable and dlgJob.
Jasmin
2011/1/10 Guillaume Lelarge <guillaume@lelarge.info>
Le 10/01/2011 11:31, Jasmin Dizdarevic a écrit :Good for you. Did you check on every dialog? do you have a patch to send> 2011/1/10 Guillaume Lelarge <guillaume@lelarge.info>
>
>> Le 10/01/2011 11:07, Jasmin Dizdarevic a écrit :
>>> Sure, it's possible, but then you have take care of each control
>>> individually. Setting a text in a combobx and checkbox is quiet
>> different.
>>> I think this change is acceptable, because the label control is kept.
>> Only
>>> the control, which is also not accessible by a tab is hidden.
>>>
>>>
>>> Radio buttons could not be covered this way. The items would have to be
>>> disabled manually.
>>>
>>> Resizing should not be a problem (in my test there were no problems),
>>> because the control is replaced through wxSizer::Replace(). So it's kept
>> in
>>> the "grid flow".
>>>
>>
>> "Resizing should not be a problem"... that's a good one :-D
>>
>
> Have you ever had problems with it? ;-)
>
>>
>> I hope you're right. But, from my experience, there's always something
>> weird in resizing.
>>
>
> As I can see and can understand what you mean - there are really no issues,
> I've just replaces a comment field that grows with the window and there are
> no issues. Also overloading the textfield with text (> 150 signs) works
> perfect.
>
to us? and a branch on your git that I can get a look at?
--
Attachment
Le 10/01/2011 12:21, Jasmin Dizdarevic a écrit : > [...] > you will need this two patches - i hope it works. > I'll take a look. > I'm interested, how you would take a look on a branch of mine. This would > make things a lot easier at all? > It should. You can do that with github for example. You should probably read http://blog.guillaume.lelarge.info/index.php/post/2010/10/04/How-to-work-with-pgAdmin-s-Git-repository > I've tested three dialogs until now. dlgDatabase, dlgTable and dlgJob. > -- Guillaume http://www.postgresql.fr http://dalibo.com