#foswiki 2015-07-26,Sun

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
GithubBot[ChecklistPlugin] gac410 pushed 4 new commits to master: http://git.io/vYzRT
ChecklistPlugin/master 1c4e452 George Clark: Item1930: Item12141: Item13557: Refresh ChecklistPlugin...
ChecklistPlugin/master 909a213 George Clark: Item13557: Perltidy
ChecklistPlugin/master bf95261 George Clark: Item13557: Regex adjustments...
[00:12]
***GithubBot has left [00:12]
FoswikiBothttp://foswiki.org/Tasks/Item1930 [ Item1930: ChecklistPlugin: Use PUBURLPATH instead of PUBURL for SafeWikiPlugin compatibility ] http://foswiki.org/Tasks/Item12141 [ Item12141: ChecklistPlugin cannot handle arbitrary DocumentGraphics ] http://foswiki.org/Tasks/Item13557 [ Item13557:
..CheckistPlugin not compatible with Foswiki 2.0 ]
[00:12]
GithubBot[ChecklistPlugin] gac410 tagged 1.200_25_Jul_2015 at master: http://git.io/vYzRY [00:13]
***GithubBot has left [00:13]
.......................... (idle for 2h6mn)
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vYz6S
distro/master 6112663 George Clark: Item13558: Fix typos in css
[02:19]
***GithubBot has left [02:19]
FoswikiBothttp://foswiki.org/Tasks/Item13558 [ Item13558: Error is style_src.css file ] [02:19]
............................................... (idle for 3h51mn)
***ChanServ sets mode: +o CDot [06:10]
.............................................................................. (idle for 6h26mn)
ChanServ sets mode: +o gac410 [12:36]
...... (idle for 27mn)
jomohi gac410, is possible somewhat easily list all modifications what is done in some file with git? I know, the "git log --follow filename" shows me the history of the given file, but i want see not only the log - but also what is changed in the given file. [13:03]
gac410If you are interested in a particular range of lines, you can use the -L option.... Can be a bit confusing.
git log -L start,end:path
[13:04]
jomook going to check this [13:04]
gac410So git log -L 1413,1414:style_src.css      showed I broken the CSS
or git log -L 1413,1414:core/pub/System/PatternSkinCss/style_src.css
er... make that git log -L 1413,1414:PatternSkin/pub/System/PatternSkinTheme/style_src.css
[13:05]
jomoor maybe the better question - how do you can discover who and when removed the support of the PATTERNSKIN_JQUERY_THEME preferences variable from the file core/templates/css.pattern.tmpl [13:07]
gac410The -L also has an option to regex for a subroutine name
hm
Probably the pickaxe option .. but I have to go look that up.
[13:07]
jomobtw, again WITHOUT any "deprecation topic" for this... I begin to feel that Foswiki isn't in much better status than TWiki, just we exchanged one uncrowned king for nother two or three. :( [13:09]
gac410MichaelDaum in this case: git log -S JQUERY PatternSkin/templates/css.pattern.tmpl by the looks of it. [13:10]
jomothanx :) [13:11]
gac410Was that in a 1.1.x release? [13:12]
jomoyes 1.1.9
i know the pattern skin 2.0 breaks the otherwise holy grail "backward compat" - and it IS ok - when alternative is introdiced. Wondering how to setup a different theme for different webs - now the setting is systemwide only from configure..
or for one topic by %JQTHEME
nah - just needed cool down - don't waste your time on this... ;(
[13:12]
gac410Unfortunately the old trunk was a bit of a catch-all for experiments. A lot of stuff was done under Arthur's plan to build a new Base skin. Some of it filtered into 1.1.9, and a lot got reverted.
I'm hoping we can be in much better control with a "release from master" and a branch/merge strategy.
Looks like there were 3 commits on 1.1.x that hit that JQUERY setting. Added, and then reverted in Item12192: and then tweaked in Item12220
[13:16]
FoswikiBothttp://foswiki.org/Tasks/Item12192 [ Item12192: PatternSkin fixes and enhancements for Foswiki 1.2. ] http://foswiki.org/Tasks/Item12220 [ Item12220: Fixes and enhancements release branch ] [13:18]
jomoi havent any problems with any change (myself is FOR BIG CHANGES) :) :) :) - util here remain (some other way) achieve the same functionality. e.g. when introducing the EDITTABLE intead of the EDITROW it is ok - does the same thing. but remove some feature, without deprecation and without alternative - isnt good. [13:19]
gac410I suspect it should not have been added in the first place. Came in in 1.1.9
If I'm reading the commits correctly
[13:19]
jomono, imho in 1.1.6
or such..
[13:20]
gac410okay [13:20]
jomosome comments are in releasenotes1x1
about "ensure than every web-prefs" contains this variable :)
[13:20]
gac410I recall the addition. It was very painful, and probably should never have happened. Lots of sites got tripped up by the change in a "patch release" [13:21]
jomookay, just here isn't now any way how to set different "jqery theme variant" for different webs
at least i don't know any way
[13:22]
gac410Unfortunately we lost our primary maintainer of PatternSkin. Michael is more focused on NatSkin and has been stuck trying to keep pattern skin working [13:22]
jomoah so... unfortunate [13:23]
gac410Check out =%<nop>JQTHEME{"foobar"}%= ... claims it can set the theme
So to set it "web-wide" you'd probably use a view template to set the theme that way, rather than a preference setting ... guessing though.
configure sets the default and the JQTHEME macro can override it.
[13:26]
jomothe whole skin=templates + JavaScript + CSS is a big mess. When someone want change the PatternSking CSS, he could, easily add some CSS to any topic and set one pref var - but when restyling pattern, need restyle the JQ too, and this isn't possible soo easily - need to to system level and add some files directly to subdir in some topic's pubdir, also FW generater many CSS directly from a code - unstylable... [13:27]
gac410right. the css from code is covered under the plan to move all html generation from code into templats.
or I should say, the code I did in a feature branch overlooked that requirement. which is why it has not been merged :D
[13:28]
jomoso mess - and yes, teh JQTHEME allows one topic - but the whole web - the VIEW_TEMPLATE works, but for example when you set the global VIEW_TEMPLATE (for the web) the AutoViewTemplatePlugin stop working...
here isn't any CLEAR strategy - quo vadis - and when i ask CDot come to "talk" his reply is "no need talk, just branch and start hack" - but this is the result of "hacking" - not consistent FW... ;( ;( hopless...
[13:29]
gac410Configurabl # Template defined by form overrides existing VIEW_TEMPLATE or EDIT_TEMPLATE settings
$Foswiki::cfg{Plugins}{AutoViewTemplatePlugin}{Override} = 0;
jomo, Care to be the RM for 2.1 ? :D I've done my duty for sure ... time for fresh blood.
[13:31]
jomoHUH! NEVER! - It is much easier to be one - who only flamings.. ;) /anyway, havent enough practical skills for everyday works with git, and so.../ [13:36]
gac410neither did I excuses excuses. my first exposure to git was right here. [13:37]
jomothe only pity is - no talk here, no clear vision, where the FW heading... the ad hoc - isn't a solution. But youre killed my flaming - yes, it is much easier to talk as really DOING something. And IMHO the RM is teh HARDEST job for any opensource project!!!
and you doin'g it excellently... - the missing deprecation-requests isn't your fauls... :)
gac - if you leave FW - it will stop work soon... seroiusly.
don't even think about an new RM :) :)
[13:39]
..... (idle for 24mn)
gac410Not really a deprecation missed, or a for that matter, a feature missed either. Shouldn't have been added, shouldn't have been removed :P [14:06]
jomoah... ok then, the remove only repaired the missed feature request ;) [14:07]
gac410I'm guessing more a lack of understanding on how things fit together. in some ways fw is too bit for one dev to understand. (or at least for this RM to understand)
bit... s/b big
tbh I don't really fully understand jquery, Micha does. So jquery themes should be done the jquery way. Arthur as a pattern skin expert, skin themes should be done the skin way.
and /me can't keep track of it. If we said no change whatsoever without a fully detailed spec, the project would collapse. we are at the point where dev's scratch itches. And spec <=> code kind of flow back and forth.
So proposals generally are pretty high level, 14 day timer and no objections, poof ... it's a spec. And the details work out in the implementation.
the purpose of the 14 day timer was to try to break the utter logjam encountered in another project.
But the downside is stuff gets approved, *especially* if dev's don't take the time to read, and raise concerns.
[14:07]
jomoyeah... and it will be worse and worse... we have a great opportunity reduce the "mess" when we going to switch to REAL PSGI APP. This (based on its principe) must be backed by really big changes in the code - but here ins;t enough developers and especially enough WILL to do the change. And first, we need TALK about the future... :)
your FR about the NameFilter split - is got approved :)
[14:12]
gac410gac410 doesn't have a clue about PSGI. is it a misspelled - PSIG (Pounds-sq-inch gauge) And that's the issue. The offical flow. is ... want to change something, make a feature request. Nobody objects, done.
And yet CDot has other approach. Things filter-out is BAD ... and wants to eliminate *nameFilter altogether, with some other mechanism.
[14:15]
jomoyes, for some small changes it could work - unfortunately the PSGI change mean redone half of the FW :) [14:16]
gac410er. believes filter-out is bad' [14:16]
jomohm... and this is exactly about what i talking: " with some other mechanism." - nobody knows what he mean. Because here isnt enough talk.. [14:17]
gac410I'm sure it's buried in the feature requests somewhere. [14:18]
jomookay :) [14:18]
must gtg - brb later [14:23]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)