OK, great.
So maybe not for the form changes, but I think the idea is still
generally useful to answer the question Daniel Beck raised (below) in a
satisfactory way:
Forcing all plugins that use affected core resources to choose between
looking outdated and requiring the latest and greatest as minimum
compatible version would be a bad idea.
With the compatibility plugin, plugins can look consistent regardless of
Jenkins versions they run on, without forcing the latest & greatest
as the minimum required version.
(And in 100 or so releases, plugins can drop this plugin as a
requirement and simply start relying on the new core.)
On 06/09/2014 04:30 PM, Stephen Connolly wrote:
Ha! I got quite far retaining compatibility... There are a few plugins
that copy&paste the tags rather than using the tag directly (eg some of
the ones I wrote do that to work around bugs in the core tags in eg
1.424 or 1.460) given those baselines are quite old I suspect just
reverting back to using tags directly would be sufficient to get all
plugins working either side of the big UI switch to divs...
You can see some of our progress in the div-fanatic-experiment branch...
Still need to fix structured form submission mind you ;-)
On Monday, 9 June 2014, Kohsuke Kawaguchi <[email protected]
<mailto:[email protected]>> wrote:
I suspect we need a compatibility plugin like this anyway to hide
the layout changes (<div> vs <table>) and so on.
On 06/09/2014 03:47 PM, Kohsuke Kawaguchi wrote:
I assume we are only talking about the flashing orb here ---
other icons
(say the terminal icon) are just fine with them being images, and
whatever animations you might require (like fading, etc) can be done
with img+css.
As for the compatibility issue, what if we produce a plugin that
encapsulates the fallback behaviour?
For the flashing ball images, the said plugin can define a tag
file like:
<c:ball icon="${run.iconColor}" size="24" />
... and the tag can expand to <img> (if running on today's
Jenkins) or
<div> (if running on tomorrow's Jenkins)
On 06/06/2014 10:33 AM, Tom Fennelly wrote:
All the icons in Jenkins are hardcoded as images in the
Jelly scripts.
We were hoping to move away from this (ala Doony) by
using CSS + some
Javascript (for the animation). Seems like this is not
possible to do
without getting into screen-scraping hacks
<https://github.com/tfennelly/__jenkins/blob/orb-orb/core/src/__main/resources/lib/layout/orb.__js#L80
<https://github.com/tfennelly/jenkins/blob/orb-orb/core/src/main/resources/lib/layout/orb.js#L80>>
because the <img>s are used out in plugins too (not just in
the core
Jenkins code) e.g. the maven plugin.
I guess this means we're stuck with using images Vs CSS
+Javascript ?
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/d/__optout
<https://groups.google.com/d/optout>.
--
Sent from my phone
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
