#foswiki 2017-09-28,Thu

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

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood [03:09]
......................... (idle for 2h2mn)
ChanServ sets mode: +o Lynnwood [05:11]
......................... (idle for 2h3mn)
ChanServ sets mode: +o Lynnwood [07:14]
....... (idle for 34mn)
ChanServ sets mode: +o MichaelDaum [07:48]
.................. (idle for 1h29mn)
ChanServ sets mode: +o Lynnwood [09:17]
......................... (idle for 2h2mn)
ChanServ sets mode: +o Lynnwood [11:19]
ChanServ sets mode: +o Lynnwood [11:29]
................ (idle for 1h19mn)
ChanServ sets mode: +o gac410 [12:48]
...... (idle for 27mn)
gac410MichaelDaum: I've been pondering or ICON macro. (I know... dangerous) I'm fixing a bunch of minor structural issues on Item14493 But I've been thinking that it should probably follow our "Canonical" rules consistent with SCRIPTURL and PUBURL [13:15]
FoswikiBothttps://foswiki.org/Tasks/Item14493 [ Item14493: ICONURL and ICONURLPATH do not work with skin based ICONs. ] [13:15]
gac410So that you could render an ICON from any topic by using web= and topic= just like with ATTACHURL{}
eg. write ICON{"au.png" topic="FamFamFamFlagIcos"}% instead of needing to write the img tag directly.
[13:16]
MichaelDaumhm
actually not a good idea
[13:23]
gac410It can do that today, but you have to set ICONTOPIC to a different topic name [13:24]
MichaelDaumthe idea behind %ICON is to swap out icons of some wiki app ... withouth having to touch it actually, i.e. without having to rewrite any %ICON macro
just switch to a different icon set and boom
so the idea
[13:24]
gac410You could still to that. Allowing an override doesn't preclude it, just allows one-off convenience. [13:26]
MichaelDaumMichaelDaum trying to understand _lookupIcon ().... :| [13:26]
gac410It expects it as an attachment to DocumentGraphics. OR a *template* override TMPL:DEF{image:<youriconname>
To swap out a whole set, you either change the ICONTOPIC name, or override the icons.tmpl with a skin, and create a new TMPL:DEF for each image:iconname you want
[13:27]
MichaelDaumit expects it as an attachment to ICONTOPIC [13:28]
gac410Yes
But it's all/none. FamFamFam is great, but if it's not attached to DocumentGraphics, you can't get there from here without writing <img tags.
And the TMPL:DEF overrides are horribly arcane
When you enter ICON{"foo" it tries to render TMPL:DEF{image:foo and then looks for attachment to ICONTOPIC
[13:28]
MichaelDaumI see [13:31]
gac410So following our "never cyange SYSTEM web rule. ICONTOPIC should be a list - Someweb.MyGraphics, System.DocumentGraphics too. [13:32]
MichaelDaumNow I remember that I once wanted access to the famfamfams and tried %ICON as well
yes that would be a good idea: make ICONTOPIC a kind of search path
[13:32]
gac410And allowing ICONTOPIC to be overridden as a one-off in the macro makes it easier to try, or grab individual icons from anywhere without duplicating. [13:33]
MichaelDaumnote that if all you want is access to famfamfam, %JQICON is the better way to do so [13:33]
gac410Ah. damn Completely forgot about that one :P [13:34]
MichaelDaumfurther note that this way of having icons via %ICON is bound to icon _images_ ... the modern way is font icons ... and these don't ever materialize as individual attachments ever.
such as http://fontawesome.io/icons/ or https://material.io/icons/
[13:35]
FoswikiBot[ Material icons - Material Design ] [13:36]
gac410y, hmmm So should we really deprecate ICON for JQICON, Is the old ICON brute force render / template icon rendering obsolete. This all seems like too many cooks.
The FamFamFam override is really difficult, and having a contrib templates used by core macros / overriding foswiki.tmpl was really wrong.
Oh well. I got distracted trying to help zac256 fix his icons.tmpl skinning of icons, And proceeded down what I thought was a low-hanging fruit AKA a rat-hole
[13:36]
MichaelDaumthese icons are really nice actually: https://blog.foswiki.org/System/JQueryFontAwesome https://blog.foswiki.org/System/MaterialIcons [13:39]
FoswikiBot[ Material Icons | System | Foswiki Blog ] [13:39]
gac410Yes, they really are quite nice. [13:40]
MichaelDaumand of course %ICONURL(PATH doesn't make any sense at all for icon fonts ... nor Foswiki::Render::IconImage as it is atm [13:40]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Render::IconImage [13:40]
MichaelDaumnote that there is already {JQueryPlugin}{IconSearchPath}
for image icons
[13:42]
gac410Right. I was reaching the conclusion that Render::IconImage should just die. And be part of Macros::ICON, and strictly use templates not brute force
Maybe ICON should just be a shim, mapping into JQICON
[13:42]
MichaelDaumor replace vice versa after JQICON has been moved out of JQueryPlugin and into the core [13:43]
gac410Y I was just thinking a bout the badness of core using extension Bad developer ... BAD! So right move is to subsume JQICON implementation into ICON, and have JQICON an alias for an updated ICON implementation.
I really don't see how Sven's custom image:foo template for every icon made much sense. Trying to understand wtf it was doing was painful.
gac410 senses he has fallen into a rat-hole, and was only going to be adding lipstick on the proverbial pig.
Anyway, I'm committing the fixes to icons.tmpl and foswiki.tmpl that I've already made. But will abandon any deeper work.
Maybe I'll add a recommendation to the DocumentGraphics customization page, referencing JQICON as a better solution.
speaking of the devil... were your ears burning zak256 ... Hi There!
[13:45]
zak256Hi gac410. What's up? Sorry, I wasn't logged in and didn't read anything? [13:55]
gac410I was just chatting with MichaelDaum about ICON and the mess that it is.
JQICON is a much nicer solution for things.
[13:55]
zak256zak256 googles JQICON [13:56]
gac410nah... Foswiki:System.VarJQICON [13:56]
FoswikiBothttps://foswiki.org/System.VarJQICON [ VarJQICON ] [13:56]
gac410Or see: https://blog.foswiki.org/System/JQueryFontAwesome https://blog.foswiki.org/System/MaterialIcons
Rather than trying to fix up ICONURL(PATH) ... we really ought to be thinking about (someday) pulling JQICON feature set down into ICON, and deprecating the old implementations.
Everythign I've been thinking that ICON should do. ... JQICON already does, and 10x more.
[13:56]
zak256ok... so, sorry... was just distracted...
I will read this and think about it. So JQ means this is all javascript then?
JQuery
[14:05]
FoswikiBotJQuery is "IncompatibleWith" 1.1.9 and earliere [14:06]
gac410zak256: Looks like it generates <img tags. It's just part of JQueryPlugin [14:09]
zak256Okay... the important question is, will all the non-JQICONS work with JQICON-syntax interchangeably? ...and can I add userdefined icons here as well?
I will just read and try it out...
[14:11]
gac410user defined? probably easier. As it has an ICON search path, you could add a topic to the head of the list. Icon renders from the first topic it finds the attachment.
The more I look at this, we really ought to pull JQICON into core, and replace ICON with it's functionality. It is totally wasted time to try to fix the old ICON implementation.
[14:12]
zak256so the filename equals to the value of what has to be given to the JQICON macro
If it works, I have no problem with it.
I mean replacing ICON with JQICON
[14:14]
gac410in a topic, write %ICON{"star"}% ... %JQICON{"star"}% and you'll see the difference
First one only accesses DocumentGraphics (or the topic set in ICONTOPIC setting) ... 2nd searches the FamFam topics
[14:16]
***ChanServ sets mode: +o Lynnwood__ [14:18]
zak256ok... with "star" I actually get two different icons :-) [14:18]
gac410Add System.DocumentGraphics to the front of $Foswiki::cfg{JQueryPlugin}{IconSearchPath} , and you then get the same old DocumentGraphics icon [14:19]
zak256ICON-star is a white star in an orange box, JQSTAR is a yellow star
And for my extra icons in my skintemplate topic I just need to add the icons as attachments, with the filename I want to have as macro value?
[14:19]
gac410yes. Same as ICON, except with ICON, you have to attach to System.DocumentGraphics, or finagle with an icons.tmpl override. With JQICON you add a new topic to the front of the IconSearchPath [14:21]
***ChanServ sets mode: +o Lynnwood [14:22]
zak256But I cannot set for example icon specific title attributes then, can I? these have to be set within the macro then? [14:22]
gac410I'm not sure though if there is any way to replace ICON with JQICON by using a * Set statement.
Yes. In that regard, I think the template is a more flexible solution.
[14:22]
zak256So I can still use my template with JQICON? [14:23]
gac410That's a good question for MichaelDaum ... Any way to associate title, and alt text with the icon filename
no I don't think so.
TBH right now I've just been brainstorming a bit here on what to do about ICON. JQICON is a really nice implementation. But good point about template allowing alt= title= etc. to be stored with the icon.
[14:23]
zak256This will be mandatory in our case I am afraid. We have some icons which represent states of some kind, and the title describes that further.
Let me just play around with it later and I will give feedback.
[14:25]
gac410Y, acutally to get "accessible" , you MUST provide alt text and titles for all images. So JQICON falls down a bit in that area .. no default [14:27]
zak256Hmm [14:27]
gac410Ideally the Icon topic should have a simple table of icon | alt | title | ... to establish defaults for all img tags. [14:29]
zak256that would be great [14:29]
gac410But this all falls into "if wishes were fishes ..." [14:29]
zak256and it might be useful to make an association between icon parameter and the actual file [14:30]
gac410anyway .. another thing MichaelDaum pointed out - icon images are "old school" the modern web way is now to use font based icons.
when font icons are used, there is no file / attchment to deal with
[14:31]
zak256not everyone has to pick up on everything that's new and hip. unicode icons are nice, but for our case inflexible.
but you have to have your icons within a font
as I said, we specifically created icons for certain cases. these will never be found in any font iconset.
And I hope you don't expect that everyone creates a new font if he want's new icons?
[14:32]
gac410So those have to stay as files. No... The whole point of JQICON is that it supports both. [14:34]
zak256ok, that's good then
still JQICON doesn't solve our icons-in-radioboxes-feature, does it?
[14:35]
gac410img style icons generate a lot of server load and traffic. An https request per img. font icons are a lot less load And no, it doesn't fix EditRowPlugin
Note that you can switch back to the old EditTablePlugin if needed.
[14:37]
***ChanServ sets mode: +o Lynnwood__ [14:38]
zak256Will the icons work then again? [14:38]
gac410I think so. You can try in bin/configure, disable EditRowPlugin and enable EditTablePlugin. [14:39]
zak256But to be honest, I don't want to use obsolete stuff somewhere... I still hope to find some other workaround. [14:39]
gac410I used to be able to enable it on a topic by topic basis ... but that stopped working, I have no idea why.
We had originally removed EditTablePlugin from the 2.x release, but added it back disabled by default, due to some corner compatibility cases that we have been unable to fix.
CDot would probably work on them if someone hired him. But he didn't have the bandwidth or interest to keep fixing.
The rendering icons in edit, and empty cell when including a table probably both are in that category.
[14:40]
GithubBot[distro] gac410 pushed 3 new commits to master: https://git.io/vdOW6
distro/master 3d5491c George Clark: Item14323: Update docs - include changelog of tmce editor
distro/master 25e481a George Clark: Item14493: Restructure ICON Templates...
distro/master 58ae72c George Clark: Item13883: Docs on skin template comments broken
[14:43]
***GithubBot has left [14:43]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ]
https://foswiki.org/Tasks/Item14493 [ Item14493: ICONURL and ICONURLPATH do not work with skin based ICONs. ]
https://foswiki.org/Tasks/Item13883 [ Item13883: Documentation changes for master and 2.1 ]
[14:43]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vdOl0
distro/Item14288 1e029a0 MichaelDaum: Item14288: Merge 'origin/master'
[14:49]
***GithubBot has left [14:49]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [14:49]
***ChanServ sets mode: +o Lynnwood [14:51]
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood
[14:56]
gac410zak256: One way around all this is to use macros. ie, Set state:open = %JQICON{"star" title="Open task" alt="open" ... }% then use %state:open% as your icon
That way you don't have to deal with arcane template language, and it can be user editable.
So in your WebPreferences for your wiki app, define a bunch of local %macros% to use in place of the %ICON macros.
[15:08]
***ChanServ sets mode: +o Lynnwood [15:13]
ChanServ sets mode: +o Lynnwood [15:18]
ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o Lynnwood
[15:26]
ChanServ sets mode: +o Lynnwood [15:36]
ChanServ sets mode: +o Lynnwood [15:49]
zak256gac410: Thanks for the hint. But to be honest for know everything works as it is right now for us (except the icons in the edittable), so there is really no reason to change that again now. But I will definitely keep this in mind for further refinement later. [15:50]
gac410sure. Just pointing out that there are multiple solutions. [15:51]
***ChanServ sets mode: +o Lynnwood__ [15:55]
gac410The only parameter on ICON that JQICON does not support is "quote=" ... In our core topics, there is only one place it's used, and that is in the WikiGroups add/remove user code.
And that is easliy fixed by removing the quote= and escaping with \" where needed.
So with this setting, you can switch the whole site over to using JQICON ... provided any quote= params are fixed.
  * Set ICON = %JQICON{"%DEFAULT%" alt="%alt{default=""}%" title="%title{default=""}%"}%
Oh.. and adding DocumentGraphics to the end of the jqicon search path ... some of the foswiki specific icons are not covered by FamFam
[15:58]
.............. (idle for 1h5mn)
zak256gac410: I think nobody used the quote parameter for ICONs here yet, so at least that won't be a problem.
Are public websites published by the PublishPlugin processed by Foswiki code somehow when they are accessed? I mean is there a performance issue?
[17:06]
gac410I've not use that one, but AFAIK it's a static rendering of pages. I don't believe they have any dynamic functionality. But again, my comments are worth $.02 if that. [17:08]
zak256Someone wrote a script to make these pages available outside of the wiki url path directly and I cannot think of a reason why he did that.
Anyway... there are so many things to look into here... Thanks again for the input today, but for today I am off.
[17:10]
gac410okay... have a good evening. [17:11]
zak256You too [17:11]
***zak256 has left [17:11]
Lynnwood__Greetings everyone
I've gotten reports about issues with top menu in IE explorer (gad...)
[17:23]
gac410I've never used it. [17:25]
Lynnwood__I was able to replicate issue running IE11 in Windows. I took a look at JQueryPlugin settings for IE compatibility and they seem to be for older versions.
gac410 I hear you... I can't imagine...
But in some organzations you can hardly argue... they do what they do...
It works fine using Edge in windows.
Not even testing FF or Chrome cause i expect they are fine also in windows.
[17:25]
gac410By top menu, do you mean the HorizontalNavigaion in pattern skin or the olt TopMenuskin. [17:29]
Lynnwood__well... actually... this is NatSkin which may also use HorizontalNavigation.
let me try switching skins
well... i don't have HorizontalNavigation enabled for pattern i guess...
[17:29]
gac410Probably best to wait and ask Michael. nat is his baby [17:33]
Lynnwood__actually... i was able to solve the issue.
The root of the problem was not with the menu but with the js in updates plugin.
I saw in the console that there was js error from that plugin so i disabled it and now the menu is working.
i guess that error was tripping up all of the js.
[17:38]
gac410There is a new updatesPlugin in testing, but it still has an issue when multipel extensions are needing update [17:53]

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