Re: [Phpmyadmin-devel] about PMA_THEME_VERSION
Hi all I think this should go to -devel so I post it here :-). On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated.
I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times. However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme). The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version... -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated.
I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme).
Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version...
It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0. Marc
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated. I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme).
Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version...
It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0.
i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables but of course we could make the theme version independent of phpMyAdmin version -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated. I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme). Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version... It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0.
i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables
but of course we could make the theme version independent of phpMyAdmin version
I'm not saying that we have to use 2 variables in info.inc.php, just internally. With version_compare(), how do you implement this: if ($theme_generation != PMA_THEME_GENERATION) continue; // different generation if ($theme_version < PMA_THEME_VERSION) continue; // too old version
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated. I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme). Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version... It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0. i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables
but of course we could make the theme version independent of phpMyAdmin version
I'm not saying that we have to use 2 variables in info.inc.php, just internally.
With version_compare(), how do you implement this:
if ($theme_generation != PMA_THEME_GENERATION) continue; // different generation
if ($theme_version < PMA_THEME_VERSION) continue; // too old version
this is not required if (! version_compare($pma_theme_version, $theme_version)) { $display_outdated_theme_warning = true; } -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
I discussed with Sebastian and I would like your opinion, since Sebastian and I disagree.
In the doc we say "Themes within same generation should be backwards compatible - theme with version 2 should work in phpMyAdmin requiring version 1.
Themes with different generation are incompatible."
In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and PMA_THEME_GENERATION.
In Theme.class.php, there is a checkVersion() function that 1. uses version_compare(), which would not give the level of verification we need, and 2. is never used :)
Sebastian says that a user should see all the installed themes and be able to choose them, even if they are not compatible; he says that a user should be able to notice by himself that a theme is outdated. I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme). Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version... It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0. i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables
but of course we could make the theme version independent of phpMyAdmin version I'm not saying that we have to use 2 variables in info.inc.php, just internally.
With version_compare(), how do you implement this:
if ($theme_generation != PMA_THEME_GENERATION) continue; // different generation
if ($theme_version < PMA_THEME_VERSION) continue; // too old version
this is not required
if (! version_compare($pma_theme_version, $theme_version)) { $display_outdated_theme_warning = true; }
I think we have a misunderstanding about the meaning of the generation and version numbers. Take the aqua theme. We have the aqua-2.1.zip file in which the generation is 2 and the version is 1. So generation is the major number and version is the minor one. The goal (at least in PMA 2.7.0) is that the generation (major number) must be identical for the theme to work at all. Theme 2.1 and PMA requires 3.5 -> theme rejected Theme 4.0 and PMA requires 3.5 -> theme rejected For the minor number (version), it was rejected only if lower. Theme 2.8 and PMA requires 2.8 -> theme accepted Theme 2.8 and PMA requires 2.6 -> theme accepted Theme 2.4 and PMA requires 2.6 -> theme rejected The goal of accepting a minor theme version greater than what PMA expects was to use a recent custom theme (say 2.6) with an older PMA version (but the major number must always be identical). Probably the newer theme has more CSS into it and the older PMA version does not use it so everything is ok. So we no longer permit that? When exactly should we increase the minor version number now? Also, please try if (!version_compare('2.6','2.6')) echo "not"; I get "not". Marc
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I think this should go to -devel so I post it here :-).
On Wed, 02 Aug 2006 08:23:31 -0400 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
> I discussed with Sebastian and I would like your opinion, since > Sebastian and I disagree. > > In the doc we say > "Themes within same generation should be backwards compatible > - theme with version 2 should work in phpMyAdmin requiring version 1. > > Themes with different generation are incompatible." > > In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and > PMA_THEME_GENERATION. > > In Theme.class.php, there is a checkVersion() function that > 1. uses version_compare(), which would not give the level of > verification we need, and > 2. is never used :) > > Sebastian says that a user should see all the installed themes and be > able to choose them, even if they are not compatible; he says that a > user should be able to notice by himself that a theme is outdated. I think showing all themes is sensible way to go. Otherwise if user installs old theme, it is hard to find out what's going on. And I saw such problem several times.
However user might not be able to notice this himself, so I'd put warning on bottom of main.php if theme is outdated (saying that some parts might be displayed wrongly due to too old theme). Yes, or add something like "outdated" in the dropdown next to an outdated theme?
The only problem is how to check whether theme is compatiblem. I thought generation/version will be best solution when I wrote that code, because I expected theme changes don't have to be with each version... It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0. i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables
but of course we could make the theme version independent of phpMyAdmin version I'm not saying that we have to use 2 variables in info.inc.php, just internally.
With version_compare(), how do you implement this:
if ($theme_generation != PMA_THEME_GENERATION) continue; // different generation
if ($theme_version < PMA_THEME_VERSION) continue; // too old version this is not required
if (! version_compare($pma_theme_version, $theme_version)) { $display_outdated_theme_warning = true; }
I think we have a misunderstanding about the meaning of the generation and version numbers.
Take the aqua theme. We have the aqua-2.1.zip file in which the generation is 2 and the version is 1. So generation is the major number and version is the minor one.
The goal (at least in PMA 2.7.0) is that the generation (major number) must be identical for the theme to work at all.
Theme 2.1 and PMA requires 3.5 -> theme rejected Theme 4.0 and PMA requires 3.5 -> theme rejected
For the minor number (version), it was rejected only if lower.
Theme 2.8 and PMA requires 2.8 -> theme accepted Theme 2.8 and PMA requires 2.6 -> theme accepted Theme 2.4 and PMA requires 2.6 -> theme rejected
yes, but if we don't restrict themes and just display a warning it is not necessary to now 'how' old a theme is, if version is not the same we just display the warning
The goal of accepting a minor theme version greater than what PMA expects was to use a recent custom theme (say 2.6) with an older PMA version (but the major number must always be identical). Probably the newer theme has more CSS into it and the older PMA version does not use it so everything is ok.
So we no longer permit that? When exactly should we increase the minor version number now?
Also, please try if (!version_compare('2.6','2.6')) echo "not";
I get "not".
was only a fast example, if (version_compare('2.6','2.6') !== 0) echo "not"; i used phpMyAdmin version numbers to easily track changes in phpmyadmin.css.php and apply only changes made after the theme was released tracked by the theme version - it was just the easiest way if i update a theme i give it the verion to which i updated it in phpmyadmin.css.php i can easily apply only things that changed after the last update of the theme and using phpMyAdmin version numbers makes it more transparent -- Sebastian Mendel www.sebastianmendel.de
On Wed, 02 Aug 2006 17:20:39 +0200 Sebastian Mendel <lists@sebastianmendel.de> wrote:
i used phpMyAdmin version numbers to easily track changes in phpmyadmin.css.php and apply only changes made after the theme was released tracked by the theme version - it was just the easiest way
I now also think that using same version number as phpMyAdmin uses is the best way. We modify themes almost every release, so another versioning would only follow our one. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař schrieb:
On Wed, 02 Aug 2006 17:20:39 +0200 Sebastian Mendel <lists@sebastianmendel.de> wrote:
i used phpMyAdmin version numbers to easily track changes in phpmyadmin.css.php and apply only changes made after the theme was released tracked by the theme version - it was just the easiest way
I now also think that using same version number as phpMyAdmin uses is the best way. We modify themes almost every release, so another versioning would only follow our one.
and the check for an outdated theme can be placed in the last block in phpmyadmin.css.php - and if nothing changes there will be no new block and themes will not being outdated even if there version number is behind current phpMyAdmin version -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Michal Čihař schrieb:
On Wed, 02 Aug 2006 17:20:39 +0200 Sebastian Mendel <lists@sebastianmendel.de> wrote:
i used phpMyAdmin version numbers to easily track changes in phpmyadmin.css.php and apply only changes made after the theme was released tracked by the theme version - it was just the easiest way I now also think that using same version number as phpMyAdmin uses is the best way. We modify themes almost every release, so another versioning would only follow our one.
and the check for an outdated theme can be placed in the last block in phpmyadmin.css.php - and if nothing changes there will be no new block and themes will not being outdated even if there version number is behind current phpMyAdmin version
Oh! this is where checkVersion() is used! Sorry I did not remember it. Marc
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit : > Hi all > > I think this should go to -devel so I post it here :-). > > On Wed, 02 Aug 2006 08:23:31 -0400 > Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote: > >> I discussed with Sebastian and I would like your opinion, since >> Sebastian and I disagree. >> >> In the doc we say >> "Themes within same generation should be backwards compatible >> - theme with version 2 should work in phpMyAdmin requiring version 1. >> >> Themes with different generation are incompatible." >> >> In Config.class.php, Sebastian marked deprecated PMA_THEME_VERSION and >> PMA_THEME_GENERATION. >> >> In Theme.class.php, there is a checkVersion() function that >> 1. uses version_compare(), which would not give the level of >> verification we need, and >> 2. is never used :) >> >> Sebastian says that a user should see all the installed themes and be >> able to choose them, even if they are not compatible; he says that a >> user should be able to notice by himself that a theme is outdated. > I think showing all themes is sensible way to go. Otherwise if user > installs old theme, it is hard to find out what's going on. And I saw > such problem several times. > > However user might not be able to notice this himself, so I'd put > warning on bottom of main.php if theme is outdated (saying that some > parts might be displayed wrongly due to too old theme). Yes, or add something like "outdated" in the dropdown next to an outdated theme?
> The only problem is how to check whether theme is compatiblem. > I thought generation/version will be best solution when I wrote that > code, because I expected theme changes don't have to be with each > version... It's possible to split the new $theme_full_version in 2 parts and do a check similar to what was in 2.7.0. i would prefer using version_compare() and a single version number (2.3) and not splitted up in two variables
but of course we could make the theme version independent of phpMyAdmin version I'm not saying that we have to use 2 variables in info.inc.php, just internally.
With version_compare(), how do you implement this:
if ($theme_generation != PMA_THEME_GENERATION) continue; // different generation
if ($theme_version < PMA_THEME_VERSION) continue; // too old version this is not required
if (! version_compare($pma_theme_version, $theme_version)) { $display_outdated_theme_warning = true; }
I think we have a misunderstanding about the meaning of the generation and version numbers.
Take the aqua theme. We have the aqua-2.1.zip file in which the generation is 2 and the version is 1. So generation is the major number and version is the minor one.
The goal (at least in PMA 2.7.0) is that the generation (major number) must be identical for the theme to work at all.
Theme 2.1 and PMA requires 3.5 -> theme rejected Theme 4.0 and PMA requires 3.5 -> theme rejected
For the minor number (version), it was rejected only if lower.
Theme 2.8 and PMA requires 2.8 -> theme accepted Theme 2.8 and PMA requires 2.6 -> theme accepted Theme 2.4 and PMA requires 2.6 -> theme rejected
yes, but if we don't restrict themes and just display a warning it is not necessary to now 'how' old a theme is, if version is not the same we just display the warning
The goal of accepting a minor theme version greater than what PMA expects was to use a recent custom theme (say 2.6) with an older PMA version (but the major number must always be identical). Probably the newer theme has more CSS into it and the older PMA version does not use it so everything is ok.
So we no longer permit that? When exactly should we increase the minor version number now?
Also, please try if (!version_compare('2.6','2.6')) echo "not";
I get "not".
was only a fast example,
if (version_compare('2.6','2.6') !== 0) echo "not";
i used phpMyAdmin version numbers to easily track changes in phpmyadmin.css.php and apply only changes made after the theme was released tracked by the theme version - it was just the easiest way
if i update a theme i give it the verion to which i updated it
in phpmyadmin.css.php i can easily apply only things that changed after the last update of the theme and using phpMyAdmin version numbers makes it more transparent
Michal said that when he implemented a theme generation and version number, he expected that themes changes would not happen with each version, this is why the theme generation and version did not follow PMA's version. Maybe now, theme changes are so frequent that this no longer applies? If I understand you correctly, you suggest that the theme version for PMA 2.9.x should be 2.9 ? If yes, we will have to release custom themes with the new versionning: http://sourceforge.net/project/showfiles.php?group_id=23067 Marc
the negative effect of not checking compatibility/version can be seen on Demo (pma.cihar.com/HEAD-config/ - thx Michal, great service! ) if you choose theme "garvBlue": header is displayed incorrectly, navi-select-db not working (FF) at all .... -- View this message in context: http://www.nabble.com/Re%3A-about-PMA_THEME_VERSION-tf2039694.html#a5618455 Sent from the phpmyadmin-devel forum at Nabble.com.
Jürgen Wind a écrit :
the negative effect of not checking compatibility/version can be seen on Demo (pma.cihar.com/HEAD-config/ - thx Michal, great service! ) if you choose theme "garvBlue": header is displayed incorrectly, navi-select-db not working (FF) at all ....
Yes, and even when clicking on Theme/Style and listing the available themes, we have a confusion because sometimes the version number means the PMA's version (2.8), sometimes it means the "generation.version". Marc
participants (4)
-
Jürgen Wind -
Marc Delisle -
Michal Čihař -
Sebastian Mendel