Oleg's FontAwesome plugin about jsgrid

[flack]

Yes, we should definitely move away from the outdated jquery ui look. I'm not sure why FontAwesome needs a plugin (I would have done this in CSS/LESS for better separation of display and logic), but we might still merge it. In any case, I think the plugin from Oleg's branch should be compatible to our current codebase, so it should be possible to use it right away.

The merging in general is problematic: We have been discussing with Oleg for weeks now, and he basically hates almost everything we did and demands that we undo it. At the same time, he continues to rewrite the entire codebase without any regard for other people's input. Our last merge was not even five days ago, and (at the time of this writing), he has already made 33 more commits with 5792 additions and 4658 deletions: free-jqgrid/jqGrid@OlegKi:69d206b581f33d7ae3495362495e297d283022f9...master

We are still trying to resolve this in a manner that is beneficial to all involved parties, but I must admit that I'm not overly optimistic.

[bouks]

If we are leaving jqueryUI, are we ready to include a dependency to another project (managing updates...) ?
Font awesome feels good but is it a good way to use it with +60ko for just maybe 10 icons ?

[flack]

My idea would be to offer different themes that the user can choose from: Switchung from something based on jquery ui to e.g. something based on bootstrap should be possible by just switching to a different stylesheet. for example, we could make a less file that loads bootstrap.less and then maps the BS selectors to the corresponding jqGrid ones (the same goes for fontawesome and the like). This means that we would only have a build-time dependency on those other frameworks, and the user only needs to include the file he actually plans to use

[smartcorestudio]

Ideally in the far future maybe it should be something like this: http://www.datatables.net/manual/styling/ (although in their case they had to change both JS and CSS)

[bouks]

I'm not fan of boostrap and overusing non semantic classes. :)
Also the grid is, in my mind, mainly for back offices. So do we need advanced theming ?

But why not add this for better free theming if you want.

[flack]

Just a small example of how I imagine integrations could work:

@import (reference) "fontawesome/icons.less"

.ui-jqgrid .ui-icon-circle-triangle-n
{
    &:before
    {
        content: @fa-var-chevron-circle-down;
    }
}

This will only render the CSS selector we actually need (it's dummy code, so of course some more parts need to be added for it to actually work). We will of course have to load the entire webfont file. but all in all it would be simple to do, and it is optional, if you don't want to use it, you can just ignore the generated CSS file

[OlegKi]

@smartcorestudio I though to make support of vector-based icons of FontAwesome as the first feature of new version of jqGrid, but after analyzing how many places of jqGrid code I would need to change I do decide to use existing plugin at the beginning and implement more flexible styling (at least of icons) later.

I want to stress that I plan currently to make only icons replaceable with icons outside of jQuery UI. About two years ago I wrote the question, posted the request, this one and some time later I posted the request to jQuery UI theam.

Scott González answered only

We're actively working on a new CSS framework. You should look at what's being done in jQuery Mobile 1.4 to get an idea of what we're working on and how the fallbacks from SVG to PNG works.

I waited some time, but I think that it's better to make jqGrid more flexible and allow to replace all icons used by jqGrid with another icons of jQuery UI Framework or any another foreign icons like FontAwesome.

So one still need jQuery UI CSS. Probably I'll change jqGrid code so that all classes used by jqGrid will be more flexible and could be configured (to use Bootstrap only for example). In the case one would divide ui.jqgrid.css into the main part which is independent from jQuery UI classes and the port which depends on jQuery UI (which uses .ui-icon, .ui-menu and .ui-menu-item). In any way it's not the feature of the next release.

@flack : I don't "hates almost everything you did". Really! I wrote that I find very good new build system, download portal and new new structure of documentation site. But I see really no advantage of the usage of LESS in jqGrid and not always agree with some changes of the code.

I wrote before that I use now a pause between projects which I implement for my customers (not for free of cause). In short time I could have a break in jqGrid developing or to invest only minimal time for it. So I try to use my time mostly optimal and to make the more changes in jqGrid code (which I find important) which I can. Sorry, but i can't wait for confirmation of any other persons.

One additional wish to all: If you would find any bug in jqGrid 4.6/4.7 or in my fork please inform me. It's better to post the URL to the demo which reproduces the problem.

[flack]

@OlegKi The problem is mostly one of communication. I have adressed all your questions about less multiple times, but you just don't seem to acknowledge my answers (just see the comment directly above yours for another example of something you can do in less and not in css). Collaboration is a two-way street, it doesn't work if we try to pull all of your changes and you ignore all of ours. It is good to know that you at least like some of what we did, but what does it matter if you don't use it or contribute to it?

Maybe we should talk again when your project break is over. Right now, discussions seem kind of pointless, since you will do it your way anyways (because, like you sais, you "can't wait for confirmation of any other persons.")

BTW: If you want people to report issues with your fork, maybe you should enable github's bug tracker

[OlegKi]

@flack Thank you for the advice about enabling of "Issues" Feature in repository settings. It's enabled now. I didn't realized that the feature is not enable by default.

Sorry, if you see that I ignore the most of your changes, but I really try to consider every from your suggestion objective. You could just not convince me in case of usage LESS. I can mention for example the pull request or some close your pull requests, seems be absolutely correct. The corresponding changes are in my repository too.

I want to comment "can't wait for confirmation of any other persons." text. I mean that there are situations, when it's unclear what is better and what should be implemented. In the case the discussion is very helpful. On the other side, if it's absolutely clear what to do and how to implement, one need just take a time and to do what's required. My last activity is mostly from "clear what to do" part. So if I would explain you first some bugs, which I know, or some solutions (out of the main jqGrid code) which I did before, it would only take time. So I implement just the sings where I'm absolutely sure.

I forgot to mention one more small new feature which I implemented yesterday: I modified the code of gridResize method so that it allows only horizontal resizing of grids having width: "auto" or width: "100". I personally missed the feature before. To see what I did you can just try to resize the whole grid on the demo. It allows to sollve the problem with increasing the width of the last column.

[flack]

Ok, so I didn't convince you of less. I can live with that, I am not the less salesman. The question is: What happens now: We've discussed less mutiple times, and we have had a vote on it last week which was 4:0 for less. You didn't participate, and now you tell us "I'm not conviced". So should we ignore everybody else's opinion and just throw away our stuff because you're no convinced?

I'm glad you've mentioned this pull request, because it is a perfect example of what is wrong with the current workflow: @meh-uk did those changes. We couldn't merge them, because they were causing too many conflicts with your changes. Then, two weeks later, you decide to copy and paste the changes and commit them into your repo under your name. So meh-uk isn't even listed as a contributor in your repo, when in fact, he is. From his point of view, he did the work on the pull request for nothing, and is understandably frustrated right now, while we have yet another future merge conflict on our hands.

[smartcorestudio]

As a jqGrid user I see that having 2 free forks is counter-productive. So, @OlegKi, sorry for a frank question: what exactly do you want?

1. To have a "private", "isolated" repo where you'll be the only committer. Something like you had in your fork.
2. To be the owner of the repo where everybody can report issues, make pull requests etc, but you'll decide what to merge. Something like Tony has in original jqGrid. This means that this fork is not interesting to you, but you want to invite it's members and everyone else to help you in your fork.
3. To collaborate with other "owners" in really open project (based on this or another fork). This means that you want to contribute directly in this or based on this (renamed) repo and be the part of the team.

[meh-uk]

Oleg I think you need to be more reasonable. You can't win everything.

[OlegKi]

It was many comments above so I'll answer with separate posts.

First of all about the question with LESS. I mention the problem in my answer only after Andreas (flack) used it as an example that I disagree with other.

Probably the sentence "You could just not convince me in case of usage LESS" I wrote not exact in English. In German if would be "Sie haben mich nicht überzeugt" and in Russian: "Вы меня не переубедили". With the words I mean just what I wrote: I wrote what I personally still think about it. About the common way I wrote already (in the email) that I can good live with LESS in general after Andreas (flack) changed the build so that uncompressed CSS file will be created. My later remarks about LESS files was only about the content of the files from https://github.com/openpsa/grid.js/tree/master/less. I can include below the text from my emails which I send to you. I think it's not a secret

Sorry to annoy everybody with the discussion about conversion of ui.jqgrid.css to multiple LESS files.

The rule of like (see )

.ui-th-ltr {border-left : 0 none;}

is not a bug (Andreas Flack named the rule from jqGrid ui.jqgrid.css as a bug in his previous email). One do can specify CSS rule on one class only, but the th elements (from the column headers), which have the class have ui-state-default class too. The th elements are inside of gbox (the outer div which have ui-jqgrid class) which have ui-widget-content class. So, for example, the CSS rules of jquery-ui.css (see here on .ui-widget-content and below some rules on ".ui-state-default" and on ".ui-widget-content .ui-state-default") will be applied too. The original rule .ui-th-ltr will be always overwritten by ".ui-widget-content .ui-state-default" independent from the order of including of jquery-ui.css and ui.jqgrid.css files. The rule will be do applied only because the second part

.ui-th-ltr, .ui-jqgrid .ui-jqgrid-htable th.ui-th-ltr {border-left : 0 none;}

which consist from 3 elements. If you use .ui-jqgrid .ui-th-ltr {border-left : 0 none;} instead of .ui-th-ltr {border-left : 0 none;} then the CSS rule defined in ".ui-widget-content .ui-state-default" will don’t overwritten if ui.jqgrid.css file will be included after jquery-ui.css.

I wrote the above example just to stress, that changing of CSS can have side effects. What is goal and the advantages of such changes? One have the original ui.jqgrid.css file, which are used on thousands of existing web sites. If we change it then one can have side effects. So I want to make the changes which are really reasoned. Only in the case we will not spend our time in fixing of new problems.

The changes, which I did in the original ui.jqgrid.css file, can be divided in two parts:

1. Adding some rules, which are really important for layout of jqGrid, like border-collapse: separate; rule on all internal jqGrid tables (see here), which is already so on empty HTML page, but which can be do changed by other CSS files like Bootstrap, default CSS of ASP.NET MVC 2-4 and other. Including of such rules applied for jqGrid only. Such rules just improve the compatibility of jqGrid with other frameworks.
2. Replacing rules having !important to another more long CSS rule. It allows to overwrite some standard rules for customization purpose without the requirement to use in the !important rules. It allows to construct the rules, which independent from the order of included CSS files.

It’s all what I did in ui.jqgrid.css file.

So I repeat, that I my main problem is that already the second rule which I could see in grid.js-0.1.0.css can have side effects. It's not clear how many other rules (or the order of rules) are changes. Somebody should examine the rules exactly, but I repeat that I personally still see no sense in the transformation. As the result one will have the same from which one started: ui.jqgrid.css will be renamed in grid.js-0.1.0.css. It's only my opinion and I don't want to impose other.

[bouks]

What a story for just css rules...

[flack]

Well, like I said: The current less files are only a rough conversion of Tony's original CSS. We can fix small errors made during the conversion very easily. In fact, should we ever come to an agreement, I plan to recreate the less files from your current css. But before I do that, I just want to be sure that this collaboration has a future

[OlegKi]

@smartcorestudio : My plans are very simple. Independent from the activity on https://github.com/openpsa/grid.js I wanted to share my changes or bug fixes with all other. Tony just suggested me to commit to Guriddo jqGrid and I posted my first changes (in my repository) only some time later, after I finished the dialog with Tony. I don't want to go in details, but we just didn't found the way, which would be OK for both sides.

So I started to post my changes on https://github.com/OlegKi/jqGrid. In the same time I've found https://github.com/openpsa/grid.js/ were some people wanted to do the same as me. So I started and still continue the communication in searching the ways to do the development together, but we still didn't found a compromise. If somebody would do some independent part of work (or at least to be responsible for the part), it could be the simplest way of cooperation. I see building system, downloading separate components, documentation, code example, css, unit tests, other good test examples which can be used to manual verification that new changes don't break existing features, specifications and setting priority of new requirements as features, .... Somebody can just get some jqGrid module which he knows better: SubGrid, TreeGrid, Pivot, Grouping of data, Header Grouping, Frozen Columns, TableToGrid and so on. I don't want that multiple persons change in the same time the same module.

Now I just answer direct on your questions

1. To have a "private", "isolated" repo where you'll be the only committer. Something like you had in your fork.
2. To be the owner of the repo where everybody can report issues, make pull requests etc, but you'll decide what to merge. Something like Tony has in original jqGrid. This means that this fork is not interesting to you, but you want to invite it's members and everyone else to help you in your fork.

Currently I'm the only commiter of my repository, but I can add other. I would still want that you (or other) post first some pull requests at the first time. If I would see that the suggestions OK, then I would make the person a new commiter. But I want still verifying the changes, and testing there. I want to hold the right to revert the changes only if I'll find some serious problems.

3. To collaborate with other "owners" in really open project (based on this or another fork). This means that you want to contribute directly in this or based on this (renamed) repo and be the part of the team.
   I thought to rename the repo or create "organisation" repository. I communicate currently with contributer of https://github.com/openpsa/grid.js, but we still didn't found the common name.

I really like to work in team, but working in team should speed up the development and not to make it slowly. Currently we spend the most time in common discussion. One spend a lot of time in reproaching of each other. It's not what I expect from cooperation.

The "organisation" repository would be the best choice, but we still didn't find one common name. I don't want to use OpenPSA, because it's the name of the old project which was developed by Andreas before. We posted some other suggestion of the name via email, because everybody can see public communication and can catch the name for him. We still not found any common name, which at least 3 persons from 4 would find good. :-)

I try at least do my own job in improvement of jqGrid and continue to post some new staff very day. After Andreas Flack reported two bugs in my code I fixed there in very short time (less as an hour after having the demo which reproduces the bug). I will try to hold the best response time later. I suggested to make the talk via Skype. I hope we will can do this today evening at 19:00 CET (6pm UTC). If you @smartcorestudio have an interest you are welcome too.

[flack]

I thought the call was supposed to be tomorrow?

[bouks]

@OlegKi

"I really like to work in team, but working in team should speed up the development and not to make it slowly. Currently we spend the most time in common discussion. One spend a lot of time in reproaching of each other. It's not what I expect from cooperation."

I can't read that from you.

From what you wrote up this and since now, team is just impossible with you. I think you don't know what is a collaborative free open source team.

Really you start to bother me.

[bouks]

I'm not free this evening. Like @flack said, we were on wednesday.

@OlegKi wrote on 2015-01-17 "For example Wednesday 20, at 19:00 CET (6pm UTC) would be OK for me."

[bouks]

Ho. i see the error you commit @OlegKi suggested wednesday by matthew is not the 20 !

[bouks]

Wednesday is the 21 !

[OlegKi]

@smartcorestudio : I want come back from common discussion back to the main question: to @ 14px of the font size. I used small size because the current version of jqGrid have restriction in the navigator bar. So the navigator buttons (in case of many buttons) can overlap the pager buttons (from the middle). You can see the problem it you would decrease the width of columns of the grid or the whole grid. I wanted to make some changes in navigator bar (probably I'll post it today or tomorrow) so that the navigator buttons will be placed in multiple rows automatically. After that one will be able to use more large icons.

In any way the font size is easy to configure. The demo demonstrates what you can do. I added just the line

$.extend(true, $.jgrid.icons, {
    common: "fa fa-lg"
})

and

.ui-subgrid > .subgrid-cell span.ui-icon.fa {
    margin-bottom: 4px;
    margin-left: 2px;
}
.jqgrow > .ui-sgcollapsed span.ui-icon.fa {
    margin-top: 4px;
    margin-left: 0px;
}
.ui-jqgrid >.ui-jqgrid-pager .navtable,
.ui-jqgrid >.ui-jqgrid-view > .ui-jqgrid-toppager .navtable {
    font-size: 14px;
}

If you examine exactly all places where vector icons will be used you will see that one would add more CSS fixes. It's clear that one can do this very easy.

This example shows once more why I didn't included support of Font Awesome 4 as the main feature. i think that HTML structure of some elements of jqGrid (like buttons of dialogs) should be a little more changes to easy support icons of different size. The current solutions is a list of hacks in existing CSS of jqGrid to make all looking OK.

I have to add, that I feel me in CSS not so good as in JavaScript. So the suggested code of Plugin is not nice from CSS point of view, but it do work.

[OlegKi]

Sorry, my error. The call will be 21 January at 19:00 CET (6pm UTC). I just never use the days of the week for appointments.

[smartcorestudio]

@OlegKi Yes, I know. Some time ago I have to integrate jqGrid with FA icons and Bootstrap. It looked like this:

But it wasn't straightforward. So it will be better if this will be more simple "out of the box"

[OlegKi]

@smartcorestudio : Who will implement this and to make it more simple "out of the box"? If you fill your good in CSS you can examine exactly the existing structure of buttons in dialog and to post your suggestion.

The buttons looks like

<a id="sData" class="fm-button ui-state-default ui-corner-all fm-button-icon-left">Submit<span class="ui-icon ui-icon-disk"></span></a>

or

<a id="fbox_li.st_search" class="fm-button ui-state-default ui-corner-all fm-button-icon-right ui-reset"><span class="ui-icon ui-icon-search"></span>Find</a>

One or multiple such <a>-buttons inside of <td class="EditButton">. One have no <span> wrapper inside of <a> over the text and the have additionally many CSS settings (see here) with fixed magrin, padding and width values. It would be better to change the structure and to make all more flexible, replaceable icons with unspecified width and height. one need just to have icons inline with the text and icons could be either on the left or on the right place relative to the text.

Could you make the suggestion and which would works with jQuery UI icons and with Font Awesome 4 of different size?

[smartcorestudio]

Yes, I've managed to tune this in my specific project, but it may be not very elegant and versatile. I see the problem: we need to find a flexible solution. I can try to investigate this at the weekend if I'll have time

[smartcorestudio]

@OlegKi I think we can simplify some things here. My proposals:

1. I don't see any real need in using those -icon-left and -icon-right classes. I think we can just use simple structure similar to those used in Bootstrap, for example :
   <a id="..." class="..."><span class="some-icon-class"></span> Some button text</a>
   and
   <a id="..." class="...">Some button text <span class="some-icon-class"></span></a>
   But it needs to make some changes in js.
2. We can avoid css rules like #nData, #pData {...}
3. I also prefer navigator buttons (prev/next) in edit dialog to have the same height as main action buttons and have no space between them
   So we can replace lines 638-666 in your repo (or 539-567 in this repo) with this:

.fm-button span { 
    vertical-align: middle; 
    display: inline-block;
}
.navButton .fm-button { 
    float: left; 
    margin-right: 0;  
    padding: .4em .5em;
}
.fm-button .ui-icon {
    margin-top: -2px; 
    margin-left: -3px; 
    margin-right: -3px;
}

I tested it with different sizes of base font and FA icons, as well as with standard jQueryUI icons. In general I advise to increase default base font size from 11px to 12px. I think 11px looks too small nowadays. Also I increased padding on .fm-button to .4em .8em. You can test it yourself and if you like the idea I can make a pull-request

[OlegKi]

@smartcorestudio : Thank you! Do you have a demo page which uses the changes of styles of fm-button buttons? Could you post me the corresponding URL? It would be better to post issues to https://github.com/OlegKi/jqGrid/issues if the suggestion are based on my current code changes of jqGrid. I think that the changing of button style are not directly connected to the thema of the current issue (FontAwesome plugin).

[flack]

After thinking about this issue for a while, I think we may have found a better alternative: Having a plugin to change the DOM so that fontawesome icons can somehow work seems like a pretty hacky solution. And this is only part of the problem, since the entire jquery ui look is outdated.

I've lookd around and found a nice bootstrap adapter for jquery ui. It is no longer maintained, but I created a fork and updated it a little. Currently, it renders our kitchen sink example like this:

It still needs some work, but I think this is a more promising approach, especially since you will get consistent styles for all other jquery ui widgets as well

[OlegKi]

@flack Thank you. I made already a lot of changes in jqGrid code to eliminate having hard coded names of icons like ui-icon and ui-icon-closethick in the code. I still need to make some changes of createModal (in grid.common.js), groupingRender (in grid.grouping.js), the methods setTreeNode and setTreeGrid of grid.treegrid.js and finally in setPager, multiSort, sortData and some other places of grid.base.js. After that jqGrid code will be flexible for the usage of icons. I plan to do this in next days and to remove jQuery.jqGrid.fontAwesome4.js, jQuery.jqGrid.fontAwesome4.css and jQuery.jqGrid.checkboxFontAwesome4.js from plugins in the main code of jqGrid. All previous works with fontAwesome4 was just the first stop for the implementation. I did so because of the complexity of the changes. I wanted to make the changes step by step with testing of the part of changes.

[flack]

@OlegKi I think removing inline styles from Javascript is a good idea, but if you remove the classnames like ui-icon-closethick, you will break a lot of installations which use their own custom CSS already. Plus, it is not even necessary to do that, the problems can be fixed in plain CSS (or more effectively in LESS, but I know you don't like that very much :-)). For example, look at this demo:

http://flack.github.io/jquery-ui-less/

It works without changing anything in jqGrid's Javascript or CSS code. So theoretically, it could be used with your Javascript, too. But not if you remove existing classes or DOM elements of course

[meh-uk]

Yeah, you've got to keep the class names as is.

[OlegKi]

Probably I expressed me not clear enough. I mean that there are a lot of places in jqGrid code where you will see the came of icon classes directly in the code. For example look at the line of jqGrid 4.7.0

...<span class='ui-icon ui-icon-search'></span>"+p.Find+"</a>"

which I want to replaced to the code where constants like "ui-icon" and "ui-icon-search" come from the options of the corresponding method or from the options of jqGrid. The default options of jqGrid will corresponds to the same jQuery UI icons as in original jqGrid, but one will be able to replace all such classes to another classes by usage the corresponding parameters.

Moreover I want that if the user specifies only one jqGrid option (something like iconSet: "fontAwesome") then full set of default jQuery UI icons used in jqGrid will be replaced with another set of Font Awesome 4.x icons. It's what I'm implementing currently.

I made some changes in jqGrid styles based on suggestions of @smartcorestudio. The main goal of the changes was simplifying the structure of CSS layout of the grid near the icons. The jQuery.jqGrid.fontAwesome4.css become much smaller after making the changes. So the replacement of jQuery UI icons to another set of icons require minimal additional CSS customization.

[flack]

Ah ok, that makes more sense. If the resulting dom stays unchanged, then this won't be a problem. Where do you plan to put the iconSet presets? It would be a bit wasteful to define e.g. the entire fontawesome iconset in grid.base.js, especially if you plan to add more icon sets in the future.

[smartcorestudio]

@flack Maybe it will be better if in the future there will be "styles" or "iconsets" something like "locales" in your current download builder? I.e. contributers can add "iconstets" as separate files to a special folder. And users can choose iconset like now they select default locale in the download builder.

[flack]

@smartcorestudio Yes, that would be an idea. But like I said, I don't really see the need for an iconset map. A CSS only solution would work just as well.

@OlegKi: Don't know if you have already seen this, but jquery ui wants to do something similar to your approach, maybe you can get some inspiration from it: jquery/jquery-ui#1411

[flack]

P.S.: @smartcorestudio to elaborate some more: If you have an iconset that covers jqgrid elements, and you decide to add a datepicker, then either the datepicker will have inconsistent icons, or you will need some glue code that somehow modifies datepickers. This mean either the user (i.e. developer) has to add extra CSS/JS for these cases, or jqgrid gets bigger, because it needs more logic.

So my proposal would be rather to use a jquery ui theme that already includes icon fonts. This means no JS changes changes are necessary, and all ui widgets (inside and outside of jqgrid) will look consistent

[smartcorestudio]

@flack About "rather to use a jquery ui theme that already includes icon fonts". Can we customize used icon fonts in this case? My example: I use FontAwesome in my project and don't use Glyphicons. I don't have anything against other iconset, I just use this one (not for jqGrid, but in general). It seems logical that I want to use this iconset in jqGrid too because:

1. For consistent look of all icons in the project
2. I don't want to load extra fonts and css
   Other people may want to use other iconfonts, which they already use in their projects. I spoke about something like we can see in this commit: free-jqgrid/jqGrid@6226a88 I just thought that this iconsets can be separated into independent files like locales and integrated in the "Download builder"

[flack]

@smartcorestudio In principle, you can customize it as far you you need. The icon mapping is done here:

https://github.com/flack/jquery-ui-less/blob/master/less/jquery.ui.theme.less#L200

So you could use fontawesome's less (available here: https://github.com/FortAwesome/Font-Awesome/tree/master/less), and create your own mapping e.g. like this:

@import (reference) 'bootstrap.less';
@import 'fontawesome.less';
@import 'jquery-ui.less';

.ui-icon-refresh {
    .@{fa-css-prefix}-refresh;
}

Of course, mappings only need to be generated once and we can add them to the distribution. It is really similar to Oleg's iconset approach, except that the mapping is managed in LESS/CSS

[flack]

P.S.: the above can of course be integrated into the download builder as well. Basically, you would have a dropdown with available icon sets, and depending on your choice, a less file like in my example will be generated and converted to CSS on the fly

[smartcorestudio]

OK. After all this will take the final shape, closer to release, if you'll need help, you can ask me to make a couple of iconset files for the most popular icon fonts such as FontAwesome.

[flack]

Cool, thanks for the offer! I'll let you know when we have something, but it could still take a while, since there are still a lot of other things to cover