Hi,
I would like to take part in this year's Google Summer of Code to implement the User Preferences proposal. I took part in GSoC two years ago, implementing phpMyAdmin's new setup script, which I hope works as intended :) Currently I am on the first year of postgraduate course for master's degree on Poznań University of Technology, specialization - Data Processing Technologies.
In accordance with project proposal, all settings would be stored in pmadb, with an option for easy export and import. User will be able to change all relevant PMA features which do not affect performance or security settings. After taking a quick glance at config.default.php I believe these settings should be considered for customization: * DROP confirmations * show executed sql (ShowSql) * LeftFrame*, table comments in tooltips * displayed rows * INSERT form customization * default files (DefaultTab*) * maybe export/import default options? * MySQL manual type * window title * SQL Query box settings * hiding some tabs under one drop-down menu (eg. I have never used Designer or Query by example for database / Import for single table)
Piotr Przybylski a écrit :
Hi,
I would like to take part in this year's Google Summer of Code to implement the User Preferences proposal. I took part in GSoC two years ago, implementing phpMyAdmin's new setup script, which I hope works as intended :) Currently I am on the first year of postgraduate course for master's degree on Poznań University of Technology, specialization
- Data Processing Technologies.
In accordance with project proposal, all settings would be stored in pmadb, with an option for easy export and import. User will be able to change all relevant PMA features which do not affect performance or security settings. After taking a quick glance at config.default.php I believe these settings should be considered for customization:
- DROP confirmations
- show executed sql (ShowSql)
- LeftFrame*, table comments in tooltips
- displayed rows
- INSERT form customization
- default files (DefaultTab*)
- maybe export/import default options?
- MySQL manual type
- window title
- SQL Query box settings
- hiding some tabs under one drop-down menu (eg. I have never used
Designer or Query by example for database / Import for single table)
Hi Piotr, thanks for your interest.
There are surely other settings that can benefit from this. Some are in config.default.php, some are maybe only on the interface, I'm not sure.
The last time we discussed about this feature, we were wondering if there should be a page regrouping user preferences, or if they should be settable individually on the related page (for example while browsing, choosing the number of rows you usually want there), or both?
There was also the question of the place where they should be stored during your work session in phpMyAdmin (avoid loading them on each click!)
We need to keep these features also in the "normal" config mechanisms ( /setup, config.default.php, config.inc.php) because the pmadb is optional and has to remain optional.
W dniu 23 marca 2010 01:22 użytkownik Marc Delisle marc@infomarc.info napisał:
There are surely other settings that can benefit from this. Some are in config.default.php, some are maybe only on the interface, I'm not sure.
Yes, this will require some information gathering on this group, and maybe some questions about this on phpMyAdmin website. It can be researched while implementing functionality current config options.
The last time we discussed about this feature, we were wondering if there should be a page regrouping user preferences, or if they should be settable individually on the related page (for example while browsing, choosing the number of rows you usually want there), or both?
I believe that everything should be on special preferences page so we do not clutter the interface and keep interface behavior consistent.
There was also the question of the place where they should be stored during your work session in phpMyAdmin (avoid loading them on each click!)
$_SESSION is the best place. Settings would be loaded once and kept in an easily available place. Cookies are out of the question as it would require too much data to be sent on each request.
We need to keep these features also in the "normal" config mechanisms ( /setup, config.default.php, config.inc.php) because the pmadb is optional and has to remain optional.
My idea is to put all user-changeable options to config.default.php, then it can be implemented as simply overwriting current config with user values. Allowed keys would be stored in $cfg array, making the list easy to modify if needed. That would also allow setup script to show which config values can be changed by end users.
Hi
Dne Tue, 23 Mar 2010 18:17:08 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
W dniu 23 marca 2010 01:22 użytkownik Marc Delisle marc@infomarc.info napisał:
The last time we discussed about this feature, we were wondering if there should be a page regrouping user preferences, or if they should be settable individually on the related page (for example while browsing, choosing the number of rows you usually want there), or both?
I believe that everything should be on special preferences page so we do not clutter the interface and keep interface behavior consistent.
I'd also prefer separate preferences page. I think we even now sometimes provide too much options in the interface.
There was also the question of the place where they should be stored during your work session in phpMyAdmin (avoid loading them on each click!)
$_SESSION is the best place. Settings would be loaded once and kept in an easily available place. Cookies are out of the question as it would require too much data to be sent on each request.
Well I don't think it should be big problem loading settings on demand from the database - Config::get('SomeSettings') would lookup in user settings in DB and fallback to value from config file.
My idea is to put all user-changeable options to config.default.php, then it can be implemented as simply overwriting current config with user values. Allowed keys would be stored in $cfg array, making the list easy to modify if needed. That would also allow setup script to show which config values can be changed by end users.
Now I can see feature request to making this list also configurable ;-).
My idea is to put all user-changeable options to config.default.php, then it can be implemented as simply overwriting current config with user values. Allowed keys would be stored in $cfg array, making the list easy to modify if needed. That would also allow setup script to show which config values can be changed by end users.
Now I can see feature request to making this list also configurable ;-).
Now that you mention it... yes, it should be configurable in setup script.
Proposal submitted to GSoC.
If you have any ideas about new options for customization, please share them on this group. All input is valuable.
Piotr Przybylski a écrit :
Proposal submitted to GSoC.
If you have any ideas about new options for customization, please share them on this group. All input is valuable.
Hi Piotr, I was wondering if "only_db" and "hide_db" should be in user prefs. On a multi-user installation I suspect that these values are not really there for security purpose. If they are, well the admin could lock them out of the user prefs, but normally these should be settable per user (and per server?)
I would add also MaxDbList and MaxTableList (with maybe a max max :) ).
Hi
Dne Fri, 02 Apr 2010 11:15:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
Piotr Przybylski a écrit :
Proposal submitted to GSoC.
If you have any ideas about new options for customization, please share them on this group. All input is valuable.
Hi Piotr, I was wondering if "only_db" and "hide_db" should be in user prefs. On a multi-user installation I suspect that these values are not really there for security purpose. If they are, well the admin could lock them out of the user prefs, but normally these should be settable per user (and per server?)
I would add also MaxDbList and MaxTableList (with maybe a max max :) ).
Well I have also some comments on list of variables to configure, but this is really a detail that can be finalized later.
2010/4/2 Michal Čihař michal@cihar.com:
Hi
Dne Fri, 02 Apr 2010 11:15:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
Piotr Przybylski a écrit :
Proposal submitted to GSoC.
If you have any ideas about new options for customization, please share them on this group. All input is valuable.
Hi Piotr, I was wondering if "only_db" and "hide_db" should be in user prefs. On a multi-user installation I suspect that these values are not really there for security purpose. If they are, well the admin could lock them out of the user prefs, but normally these should be settable per user (and per server?)
I would add also MaxDbList and MaxTableList (with maybe a max max :) ).
Well I have also some comments on list of variables to configure, but this is really a detail that can be finalized later.
Yes, my current list is by no means complete, I will have to look thoroughly at possible options. For now I am more interested in additional features (i.e. new config options) and suggestions on the script functionality.
I want to gather some information now, because when GSoC coding begins there will be less people looking at this group. I do not have high hopes, but there is always a chance for useful input :)
Piotr Przybylski a écrit :
2010/4/2 Michal Čihař michal@cihar.com:
Hi
Dne Fri, 02 Apr 2010 11:15:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
Piotr Przybylski a écrit :
Proposal submitted to GSoC.
If you have any ideas about new options for customization, please share them on this group. All input is valuable.
Hi Piotr, I was wondering if "only_db" and "hide_db" should be in user prefs. On a multi-user installation I suspect that these values are not really there for security purpose. If they are, well the admin could lock them out of the user prefs, but normally these should be settable per user (and per server?)
I would add also MaxDbList and MaxTableList (with maybe a max max :) ).
Well I have also some comments on list of variables to configure, but this is really a detail that can be finalized later.
Yes, my current list is by no means complete, I will have to look thoroughly at possible options. For now I am more interested in additional features (i.e. new config options) and suggestions on the script functionality.
I want to gather some information now, because when GSoC coding begins there will be less people looking at this group. I do not have high hopes, but there is always a chance for useful input :)
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref?
W dniu 2 kwietnia 2010 17:48 użytkownik Marc Delisle marc@infomarc.info napisał:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref?
Wouldn't that clutter the interface? I was rather thinking about adding a link to preferences in some visible place, so that after upgrade user will see that he can customize phpMyAdmin. Eg. adding a that link, along with import / export button as a new column in the "Interface" group on the main page.
Piotr Przybylski a écrit :
W dniu 2 kwietnia 2010 17:48 użytkownik Marc Delisle marc@infomarc.info napisał:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref?
Wouldn't that clutter the interface? I was rather thinking about adding a link to preferences in some visible place, so that after upgrade user will see that he can customize phpMyAdmin. Eg. adding a that link, along with import / export button as a new column in the "Interface" group on the main page.
On many pages there is a small "open a new phpMyAdmin window" at the bottom. There could be such a small icon next to it, if this panel is influenced by some user pref. Or this could be at the top. Maybe if there is a standard user prefs icon, users will notice it.
Otherwise, users will have to be very familiar with the user prefs panel to understand which panel each setting influences.
W dniu 2 kwietnia 2010 18:31 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
W dniu 2 kwietnia 2010 17:48 użytkownik Marc Delisle marc@infomarc.info napisał:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref?
Wouldn't that clutter the interface? I was rather thinking about adding a link to preferences in some visible place, so that after upgrade user will see that he can customize phpMyAdmin. Eg. adding a that link, along with import / export button as a new column in the "Interface" group on the main page.
On many pages there is a small "open a new phpMyAdmin window" at the bottom. There could be such a small icon next to it, if this panel is influenced by some user pref. Or this could be at the top. Maybe if there is a standard user prefs icon, users will notice it.
Otherwise, users will have to be very familiar with the user prefs panel to understand which panel each setting influences.
Then, we will have a link at the bottom or an icon in the tab panel. Clicking on it will show user preferences used on current page, with links leading to preferences page where clicked setting would be highlighted.
I think the best way to implement this is to pass all reads from the $cfg array (or at least all reads for user customizable settings) through some function, then in the footer all read keys can be easily accessed.
Hi
Dne Wed, 7 Apr 2010 10:47:47 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
Then, we will have a link at the bottom or an icon in the tab panel. Clicking on it will show user preferences used on current page, with links leading to preferences page where clicked setting would be highlighted.
I think that preferences window which will be different on each page would be quite confusing.
I think the best way to implement this is to pass all reads from the $cfg array (or at least all reads for user customizable settings) through some function, then in the footer all read keys can be easily accessed.
Config class already does this, but not all code is yet migrated to it.
2010/4/7 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 7 Apr 2010 10:47:47 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
Then, we will have a link at the bottom or an icon in the tab panel. Clicking on it will show user preferences used on current page, with links leading to preferences page where clicked setting would be highlighted.
I think that preferences window which will be different on each page would be quite confusing.
I was rather thinking about listing used settings by name, with each such name being a link to standard user preferences page with this one setting highlighted.
Hi
Dne Wed, 7 Apr 2010 15:21:25 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I was rather thinking about listing used settings by name, with each such name being a link to standard user preferences page with this one setting highlighted.
I haven't seen such thing before and this makes me thing it is not useful, but maybe I am wrong :-).
2010/4/7 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 7 Apr 2010 15:21:25 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I was rather thinking about listing used settings by name, with each such name being a link to standard user preferences page with this one setting highlighted.
I haven't seen such thing before and this makes me thing it is not useful, but maybe I am wrong :-).
I am just thinking of a way to make "this page can be customized" link useful, to address Marc's concern:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref? [...] users will have to be very familiar with the user prefs panel to understand which panel each setting influences.
If such link is to be added, it would have to show up on every page.
Piotr Przybylski a écrit :
2010/4/7 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 7 Apr 2010 15:21:25 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I was rather thinking about listing used settings by name, with each such name being a link to standard user preferences page with this one setting highlighted.
I haven't seen such thing before and this makes me thing it is not useful, but maybe I am wrong :-).
I am just thinking of a way to make "this page can be customized" link useful, to address Marc's concern:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref? [...] users will have to be very familiar with the user prefs panel to understand which panel each setting influences.
If such link is to be added, it would have to show up on every page.
It could simply be one link + icon that tells the user that this page is influenced by some user preference, without mentionning which one.
W dniu 7 kwietnia 2010 17:04 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
2010/4/7 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 7 Apr 2010 15:21:25 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I was rather thinking about listing used settings by name, with each such name being a link to standard user preferences page with this one setting highlighted.
I haven't seen such thing before and this makes me thing it is not useful, but maybe I am wrong :-).
I am just thinking of a way to make "this page can be customized" link useful, to address Marc's concern:
Should there be a visual clue on each panel where the panel behavior is influenced by some user pref? [...] users will have to be very familiar with the user prefs panel to understand which panel each setting influences.
If such link is to be added, it would have to show up on every page.
It could simply be one link + icon that tells the user that this page is influenced by some user preference, without mentionning which one.
Ok, but if we are already monitoring all preference reads to find out whether user has customized anything, we can as well add a jQuery message window with a simple list. Then at least user will get feedback whether the things he changed actually apply to current page.
One more thing I just thought about - if pmadb is unavailable, we can use user's DOM storage [1] (IE 8, FF 3.6, Safari 4, Chrome 4, Opera 10.50).
[1] https://developer.mozilla.org/en/DOM/Storage
Hi
Dne Wed, 7 Apr 2010 17:42:58 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
If such link is to be added, it would have to show up on every page.
It could simply be one link + icon that tells the user that this page is influenced by some user preference, without mentionning which one.
Sorry but this does not make much sense to me. I guess that even things like font size or theme will be part of these settings (it does not make much sense to maintain them separately). So that means that very page will be influenced by user settings. Adding link preferences to bottom of the page (next to open new window) might make sense (but I'm not convinced about this at all). I just think this will pollute user interface with no big benefit to users.
One more thing I just thought about - if pmadb is unavailable, we can use user's DOM storage [1] (IE 8, FF 3.6, Safari 4, Chrome 4, Opera 10.50).
Yes, good idea.
2010/4/8 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 7 Apr 2010 17:42:58 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
If such link is to be added, it would have to show up on every page.
It could simply be one link + icon that tells the user that this page is influenced by some user preference, without mentionning which one.
Sorry but this does not make much sense to me. I guess that even things like font size or theme will be part of these settings (it does not make much sense to maintain them separately). So that means that very page will be influenced by user settings. Adding link preferences to bottom of the page (next to open new window) might make sense (but I'm not convinced about this at all). I just think this will pollute user interface with no big benefit to users.
I agree, but as for theme and font size, I believe these should be still stored in cookies. If a server has pmadb disabled and user does not use the newest browser version, it would be just impossible to store these settings. Moreover, storing them in two places (new preferences and cookies) would just over-complicate code.
[1] http://www.findmebyip.com/litmus/#target-selector - local storage availability in browsers
Hi
Dne Thu, 8 Apr 2010 12:01:10 +0200 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I agree, but as for theme and font size, I believe these should be still stored in cookies. If a server has pmadb disabled and user does not use the newest browser version, it would be just impossible to store these settings. Moreover, storing them in two places (new preferences and cookies) would just over-complicate code.
My reason for this is that with permanent preferences user will expect his settings stay regardless browser he is using. And it would be quite confusing if theme and font size won't be kept while others would be.
-
Marc Delisle -
Michal Čihař -
Piotr Przybylski