2016-05-07 4:25 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > On Fri, 6 May 2016 19:01:16 +0200 Davide Andreoli <d...@gurumeditation.it> > said: > > > 2016-05-06 14:00 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > > > > > On Fri, 6 May 2016 10:08:40 +0200 Davide Andreoli < > d...@gurumeditation.it> > > > said: > > > > > > > 2016-05-06 4:01 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > > > > > > > > > On Thu, 5 May 2016 23:16:56 +0200 Davide Andreoli < > > > d...@gurumeditation.it> > > > > > said: > > > > > > > > > > or use png's - keep the svg's in the tree as "originals" but > export to > > > > > bimap > > > > > from inkscape. > > > > > > > > > > > > > This will duplicate the files in git, they are lots of files, we are > now > > > > something like > > > > 3MB of icons, I was trying to avoid cluttering the repo. The svg > format > > > > also works > > > > better with git as it's a text format, so future icon changes > commits (I > > > > plan lots of > > > > them) will be slim. > > > > > > also another problem. the resulting theme will depend on how much the > host > > > rsvg > > > lib can handle and what it does and does not render correctly from the > svg > > > file. of course often this is due to inkscape using extensions of its > > > own... > > > but the point still stands. someone can't be guaranteed the same .edj > file > > > contents because system will alter it as at edje_cc the svg is > rendered to > > > a > > > bitmap by librsvg. > > > > > > > indeed this is a good point, different rsvg can be a problem, and no rsvg > > installed can be a problem too. > > correct. none is .. even worse. even if we did merge generic loaders - > you'd > HAVE to make librsvg a hard requirements for efl. > > > > having more png data in the tree is no harm. the text format is > irrelevant > > > as > > > no one will be DIFFING the svg to figure stuff out. it's a visual > thing - > > > the > > > svg is not hand edited. it's generated by a tool. treat it as a visual > > > thing. > > > you want visual diffs. text is not relevant as it's not hand edited. :) > > > > > > > My point was not on reading the diff, it was just on not having the > binary > > file change at each icon commit. > > i don't think it really matters. :) they don't change THAt often. nowhere > near > as much as code. > > > > > Another reason I'm trying to avoid this is to keep my workflow as > simple > > > as > > > > possible, > > > > that will means I can provide more icons in less time. > > > > > > by doing so you set up our build to produce a different theme on > different > > > systems. :) > > > > > > > I start to think you are right... I will then add all the png version if > no > > one > > have other valid point on using svg. > > > > > > Ok, just leave out my icon problem for a moment... do we still want to > merge > > the generic loaders? it make sense to make the merge to me also without > > the current issue. We are merging elm in this release, causing trouble to > > users and packagers, if we think it's sensible to also merge the last 2 > > pieces > > this is the right moment IMO. > > My point is: do it now or never do it. > > this.. is a separate topic. :) and i agree with you. we already have gpl > binaries in our efl tree. they are separate binaries. i THINK we are ok as > long > as we keep the binaries for generic players as separate bins and always gpl > licensed. we have epp which is an ancient cpp from gcc that's gpl > licensed. to > date we haven't had any problems. we do this just to not require a full > compiler install to run edje_cc - also it work around the fact that > different > cpp's produce different whitespacing which can be an issue for edje_cc. > > but IANAL. i'd like to hear as much input on this as possible before > moving. > does anyone object and think that this is wrong and we go against GPL? we > keep > those binaries licensed as GPL we just happen to have them in a > "distribution" > that is a single src tree/build - where does the "distribution" line > stop/start > and the derivative work begin? linux (and bsd and others) ship gpl > binaries and > pkgs alongside bsd etc. and the distribution as a whole does not become > gpl. > where is that line? for now i'm drawing that line at the binary executable > if > that binary has by dependencies become gpl. also would that binary be able > to > be meaningfully replaced by another or dropped entirely and the > distribution > still "work". epp could be replaced by a symlink to another cpp. the > generic > loaders could be dropped and efl would work. it would. you'd miss some > extended > format handling but it'd work find. > > so what in generic loaders is gpl? > > pdf loader > xcf loader > > that's it. in fact we can merge generic players too (vlc only there) as > libvlc > is lgpl these days. >
(/me keeping this discussion alive) So no one seems to have objections on the merge proposal for both loaders and players, I then would say: !! go Tom go !! :) > > > > > > beware librsvg != inskcape. inskcape has features it can put into > svg's > > > > > that > > > > > rsvg CAN'T draw right. it's SAFER to generate the png's and use > those. > > > > > > > > > > > > > Yes, I'm aware of this. It's just a matter of checking your icons > after > > > the > > > > draw and > > > > don't use "strange" inkscape feature. I also have the idea (not > tested > > > yet) > > > > to > > > > save the files as "plain svg" instead of "inkscape svg". > > > > > > last time i tried, masking i think combined with clipping and blur did > > > this. > > > these are not strange filters. they are really common/basic. :) these > are > > > incredibly useful and having to avoid them is seriously a bit pain. > > > > > > > > > ok, we are hitting a problem with evas-generic-loaders because > it's > > > not > > > > > > merged in the efl tree. > > > > > > > > > > > > The problem is that we are now using svg icons in the elementary > > > theme, > > > > > all > > > > > > the new FDO icons are in svg format. But, now that elm is merged > in > > > efl, > > > > > > the default theme is built before the user can install > > > > > evas-generic-loaders > > > > > > and thus the theme cannot be build for the lack of the svg > loader. > > > > > > > > > > > > After some chatting we agreed that the "best" way to solve the > issue > > > is > > > > > to > > > > > > also merge evas-generic-loaders in efl. > > > > > > The alternative solution is to duplicate all the icons in a > raster > > > > > format, > > > > > > that seems really a waste of space/bandwidth/git-history on each > icon > > > > > > change and will make my work of providing icons much harder. > > > > > > > > > > > > Any objections? problems? me and cedric already agreed on this > > > solution, > > > > > > and also > > > > > > agreed that make sense to also merge emotion-generics, so we will > > > finally > > > > > > have a single efl package! > > > > > > > > > > > > > > > > > > If no objections arise I will ask TAsn to do the same git work he > > > did for > > > > > > elm (merging the git tree in a branch?) so that cedric can do the > > > > > required > > > > > > autofoo stuff (already agreed with him) > > > > > > > > > > > > > > > > > > In the mean time I have to disable :( all the new icons so that > > > everyone > > > > > > can build efl without problems. I hope this will not create some > side > > > > > > effects, as it is now possible that some old icons are missing. > Let > > > me > > > > > know > > > > > > for any issue. > > > > > > > > > > > > davemds > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > Find and fix application performance issues faster with > Applications > > > > > Manager > > > > > > Applications Manager provides deep performance insights into > multiple > > > > > tiers of > > > > > > your business applications. It resolves application problems > quickly > > > and > > > > > > reduces your MTTR. Get your free trial! > > > > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > > > > _______________________________________________ > > > > > > enlightenment-devel mailing list > > > > > > enlightenment-devel@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > > > > > -- > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > -------------- > > > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
