From: Stefan P. <st...@gm...> - 2011-04-11 20:20:19
|
Hi, I'm running a Mantis installation (just updated to 1.2.5, thanks for the update!). I'm in need to apply a custom look and managed to an extent do that via a custom CSS file enabled through $g_css_include_file with the default.css via @import. However, I'm quickly running into problems with styles being set in HTML (like issue status does set table row's bgcolor instead of applying a class) or in some cases inflexible HTML (menu is made up of a literal list of anchor tags instead of actually using the ul-tag). I believe I in at least some cases may pretty easily change the markup and separate the style into CSS from the PHP code without actually altering the current look but still give greater flexibility to customize style through CSS. Since I would like to avoid maintaining an installation with custom code changes I wonder if this is something you are interested in receiving patches for? Best regards, Stefan |
From: John R. <jo...@no...> - 2011-04-11 20:38:46
|
On 04/11/2011 04:20 PM, Stefan Pettersson wrote: > Hi, > > I'm running a Mantis installation (just updated to 1.2.5, thanks for the update!). > > I'm in need to apply a custom look and managed to an extent do that via a custom > CSS file enabled through $g_css_include_file with the default.css via @import. > > However, I'm quickly running into problems with styles being set in HTML (like > issue status does set table row's bgcolor instead of applying a class) or in > some cases inflexible HTML (menu is made up of a literal list of anchor tags > instead of actually using the ul-tag). > > I believe I in at least some cases may pretty easily change the markup and > separate the style into CSS from the PHP code without actually altering the > current look but still give greater flexibility to customize style through CSS. > > Since I would like to avoid maintaining an installation with custom code changes > I wonder if this is something you are interested in receiving patches for? I believe there is an ongoing effort towards this in the current development branch, and this sort of change IMO is not really something that should be taking place in the stable maintenance branch. I know there has already been some extensive changes toward using XHTML markup wherever possible, and we would be more than happy to have outside developers join in on making this transition happen cleanly and smoothly. Ideally, the long term goal would be a complete separation of markup and styling from the code itself via some sort of templating system, but there have been various efforts in that direction that have either gone silent or are at an impasse. In the meantime, if you are running Mantis from a git clone instead of from the tarball releases, it should be relatively easy to create a branch from 1.2.5, and then commit your local changes to it. At that point, you can share those changes on our tracker or mailing list, and you can also "rebase" those changes onto later releases of Mantis so that you don't have to reapply the changes by hand. If you would like more details on getting that set up, check the developer documentation: http://docs.mantisbt.org/master-1.2.x/en/developers/dev.contrib.html Cheers -- John Reese noswap.com |
From: David H. <d...@hx...> - 2011-04-12 10:25:17
|
On Mon, 2011-04-11 at 16:38 -0400, John Reese wrote: > In the meantime, if you are running Mantis from a git clone instead of from the > tarball releases, it should be relatively easy to create a branch from 1.2.5, > and then commit your local changes to it. At that point, you can share those > changes on our tracker or mailing list, and you can also "rebase" those changes > onto later releases of Mantis so that you don't have to reapply the changes by hand. I wouldn't recommend hacking on the 1.2.x branch unless you're simply fixing a few bugs. Large patch sets (and any major/feature changes) against 1.2.x are going to be almost useless because we can't port them directly to 1.3.x - the branches are already too different - and this will only become more pronounced as time passes. The real issue is that UI/styling changes aren't going to make it into 1.2.x because the branch is "stable". I also advise against going alone with major styling changes without collaborating with other people currently interested in this issue for 1.3.x. Regards, David |
From: Stefan P. <st...@gm...> - 2011-04-12 11:32:24
|
On Tue, Apr 12, 2011 at 12:23, David Hicks <d...@hx...> wrote: > > The real issue is that UI/styling changes aren't going to make it into > 1.2.x because the branch is "stable". I also advise against going alone > with major styling changes without collaborating with other people > currently interested in this issue for 1.3.x. > 1.3.x is the way to go then. Very good. Looking back in the dev mailing list my interpretation is that the discussion has been a little towards an "all-or-nothing" approach (which it usually tend to be when talking about GUI). I don't want to introduce a major styling change to the visuals (actually no change at all), but rather do small refactoring piece by piece without changing any looks or breaking anything (in the same way as the ongoing XHTML compliancy work seems to done) to _allow_ a custom style to be applied using CSS. In the best of worlds the semantics/HTML should have little to do with enforcing a particular look or style, that should instead be controlled with CSS (as I'm sure you know). Thus the small changes I would like to apply would be tiny steps towards that, rather than going for the total-overhaul approach (with high risk of failing because of it's daunting size, and most certainly something I cannot commit to undertake). Hence, my original question was that if you (as a project) are interested in receiving patches with these kind of improvements, or if your strategy is another (e.g. going for the total-overhaul) then I simply apply these fixes and maintain them for my own personal installation. Best regards, Stefan |
From: David H. <d...@hx...> - 2011-04-13 13:36:03
|
On Tue, 2011-04-12 at 13:32 +0200, Stefan Pettersson wrote: > I don't want to introduce a major styling change to the visuals > (actually no change at all), but rather do small refactoring piece by > piece without changing any looks or breaking anything (in the same way > as the ongoing XHTML compliancy work seems to done) to _allow_ a > custom style to be applied using CSS. The 1.3.x branch has already seen a large number of minor changes (from a variety of contributors) that have added classes, IDs, etc to allow better CSS targeting. Further development in this area is very much welcomed. > In the best of worlds the semantics/HTML should have little to do with > enforcing a particular look or style, that should instead be > controlled with CSS (as I'm sure you know). Thus the small changes I > would like to apply would be tiny steps towards that, rather than > going for the total-overhaul approach (with high risk of failing > because of it's daunting size, and most certainly something I cannot > commit to undertake). Semantics/HTML is hugely important because it can completely break the behaviour of style sheets. CSS rules should be targeting the semantics of the document rather than targeting a tag soup of style classes. Some classes and IDs are required on HTML elements however many classes aren't justified. MantisBT doesn't yet produce good semantic document structures so we've been relying too much on classes so far. > Hence, my original question was that if you (as a project) are > interested in receiving patches with these kind of improvements, or if > your strategy is another (e.g. going for the total-overhaul) then I > simply apply these fixes and maintain them for my own personal > installation. Patches are most certainly welcome for the short term future. The overarching aim is to redo most of the MantisBT front end pages with a modern semantic structure. For instance, many of the tables MantisBT uses shouldn't be tables as they're not holding tabular data (rather they're just used as an old school layout mechanism). However all of this work will take extensive time to complete and in this time the 1.3.x branch will still be usable alongside any new UI work. For what you're wanting to do there is a lot of sense in working to have patches submitted to the 1.3.x branch - even if there are more distant plans to overhaul the UI. The traditional UI will still be in use for some time to come. Regards, David |
From: Stefan P. <st...@gm...> - 2011-04-13 21:37:29
|
On Wed, Apr 13, 2011 at 15:34, David Hicks <d...@hx...> wrote: > > The 1.3.x branch has already seen a large number of minor changes (from > a variety of contributors) that have added classes, IDs, etc to allow > better CSS targeting. Further development in this area is very much > welcomed. Great! I just forked the Github mirror and had a further look and saw some of the changes made in the 1.3.x branch. I also noticed the status_config.php file in the css directory that dynamically creates css classes based on values in config_inc.php/config_defaults_inc.php. Is this design the desired way to go? I.e. keeping all kinds of visual customizations to the PHP config files, rather than having the user do a custom css file for inclusion? The downside I see is that it's really mixing up and creates dependencies between presentation (css) and logic (php) layers, instead of leveraging the natural separation of concerns achievable with css. The upside is of course that all customization options are kept to the config_inc.php file. Best regards, Stefan |
From: David H. <d...@hx...> - 2011-04-19 11:04:57
|
On Wed, 2011-04-13 at 23:37 +0200, Stefan Pettersson wrote: > I also noticed the status_config.php file in the css directory that > dynamically creates css classes based on values in > config_inc.php/config_defaults_inc.php. This was part of some temporary cleanups to remove <style> tags (in favour of using externally linked stylesheets). > Is this design the desired way to go? I.e. keeping all kinds of visual > customizations to the PHP config files, rather than having the user do > a custom css file for inclusion? Nah, it's not desired for the reasons you stated. Happy to see it go! :) David |