Port Kallithea theme to Bootstrap — WIP

#167 Declined
Deleted repository
default (e0a00758e9ba)
  1. Andrej Shadura

@Mads Kiilerich suggested I create a pull request to make the changes more visible. So here it is.

See http://lists.sfconservancy.org/pipermail/kallithea-general/2015q2/000686.html for more details.

A test instance is running at https://kallithea-scm.org/bootstrap/.

What is already done

  • Bootstrap tooltip instead of custom ones — helps get rid of some YUI code too, yay!

  • Bootstrap navbars and dropdown menus

  • Bootstrap progressbar in the statistics

  • Some parts of interface wear Bootstrap styling automagically without needing to be fine-tuned — but probably need fixing anyway.

  • Some other things.

What is broken

Many things, most notable being the changelog, source view and many tables.

Comments (22)

  1. Mads Kiilerich


    For a starter, I would love to take any safe change or refactoring that prepares for this but don't break the old theme and don't introduce bootstrap yet.

  2. Jiri Suchan

    It's definitely not a good thing to break things, but I'd oppose the "not introduce Boostrap" point. It could be useful to have the Boostrap CSS files around, so if anyone will be adding/refactoring some code in templates, the old styling could be replaced piece by piece that way.

    1. Mads Kiilerich

      I doubt extra unused files will be maintained, especially if it not really is "ready" yet.

      I think it will be hard to introduce bootstrap gradually; it will add a lot of css and change a lot of things immediately.

      1. Jiri Suchan

        I doubt extra unused files will be maintained, especially if it not really is "ready" yet.

        This feels like a false dilemma a bit - existing nice file vs. a new unmaintained file. The big advantage of Bootstrap is that it's very well documented and it consist from a lot of small reusable parts. You cant say any of that about the existing CSS file.

        I think it will be hard to introduce bootstrap gradually; it will add a lot of css and change a lot of things immediately.

        Both approaches (ie. introduce gradually vs. introduce by changing everything at once) have their trade-offs. As said above, I'd prefer to introducing it gradually for a couple of reasons: It will need a lot of effort from a single person to replace everything at once. Doing such massive task without seeing any gradual progress can be demotivating. Let's say the task will follow the 80/20 rule. If the person will give up with 80% of the transformation done, the result will be nothing. On the other hand, if the transformation will be split into a series of smaller tasks, we'll get that 80% already. It's also a bit annoying to do a code-review and testing for massive PRs, and every time someone will change CSS/templates while the PR will be opened (which can be quite a long time, as I can see the dates for the currently opened PRs), it will need to be merged, and updated.

        That's my 2 cents.

        1. Andrej Shadura author

          My opinion is that as we've released recently, if there's someone ready to invest time and effort into Bootstrap stylin, we need to switch now to make sure that we don't have to rebase this branch endlessly as it seems there's little interest in fixing it while it's hanging around somewhere else.

          I know @Mads Kiilerich insists the default branch should be kept stable, but given the interface is usable while not perfect this may be a reasonable thing to sacrifice if we fix it quickly (a couple of weeks, not a couple of months).

          1. Mads Kiilerich

            We are using the default branch in production and can't introduce regressions.

            If there is a need for a temporary regression on a development branch, then we a development branch with a different policy than the current default branch - that might be two different branches. And I don't see much benefit from having the less stable development branch in the main repository. Do you?

            The big question is of course how far it is from being feature complete and not constitute a regression. Is there a todo list?

            1. Jiri Suchan

              Sorry, I am new here - if the default branch is for production, what is the stable branch for? Anyway - if there will be introduced a new branch (let's say release/0.4.0), would this PR be accepted in there?

              1. Mads Kiilerich

                I would say that the main branch is for "as far as we know, ready for release at any point" while the stable branch is just that; "proven to be ready for release because it is as stable as possible, with only minimal lowrisk bugfix changes has been requested and made recently while no new features and unnecessary risk has been added".

                IMO, andrew's repo/branch is a perfectly fine branch, almost ready for release. As soon as everybody (or a majority) agree it is ready for release, it should be merged to the default branch.

                I'm sorry for being a jerk, but I hope we all can benefit from having a stable and tested product as a result of the conservatism.

              1. Mads Kiilerich

                Yes ... but any developer can also just create his own fork on bitbucket or his own Kallithea and work there, without having to wait for someone with upstream push access. the good thing about bitbucket self-updating PRs is that it automatically will move forward as new commits are made.

                1. domruf

                  Sure, but I think the chances that somebody not involved with the development actually tests a personal clone are rather slim, don't you think?

                  If there were an 'official unstable' clone the chances that people would test it were much bigger.

                  1. Mads Kiilerich

                    I think this PR is easier to find than a separate repo hosted under conservancy. I also think something that clearly is downstream can be much more informal and quickly make progress than something that is "official". I doubt that the name of the development repo is blocking any contribution.

                    Anyway, I am not a conservancy admin. If Andrew would prefer something like that, go ahead.

                    1. domruf

                      Okay then lets develop this in Andrews repository if he is fine with it.

                      @Andrej Shadura what do you think of enabling the issue tracker in your repository so we can create and maintain a list of things that need to be fixed before pulling it into the main repository?