On Thu, Feb 26, 2015 at 7:19 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Thu, Feb 26, 2015 at 11:19 AM, Tom Hacohen <tom.haco...@samsung.com> > wrote: > > On 25/02/15 14:52, Cedric BAIL wrote: > >> On Mon, Feb 23, 2015 at 5:41 PM, Tom Hacohen <tom.haco...@samsung.com> > wrote: > >>> On 23/02/15 16:27, Cedric BAIL wrote: > >>>> On Mon, Feb 23, 2015 at 4:56 PM, Daniel Kolesa <dan...@octaforge.org> > wrote: > >>>>> On Mon, Feb 23, 2015 at 3:55 PM, Daniel Kolesa <dan...@octaforge.org> > wrote: > >>>>>> On Mon, Feb 23, 2015 at 3:50 PM, Oleksandr Shcherbina < > >>>>>> o.shcherb...@samsung.com> wrote: > >>>>>>> Sorry guys, > >>>>>>> > >>>>>>> capital letters will be changed asap. > >>>>>>> > >>>>>>> Also we plan reduce quality of resources. > >>>>>>> > >>>>>>> It example useful for testing, because gathers features > together. > >>>>>>> > >>>>>>> Can you advice acceptable size for 3d models and images for > textures? > >>>>>>> > >>>>>> > >>>>>> 256x256 for this kind of stuff at most (everything above that is an > >>>>>> overkill; i believe in most cases even 128x128 would do). Fix up > the names > >>>>>> and paths (all lowercase, no spaces). Keep all textures with > power-of-two > >>>>>> sizes (32, 64, 128 etc) so that mipmapping behaves correctly (and > so that > >>>>>> the examples work with all versions of opengl and with all supported > >>>>>> hardware). As for the models, you can probably dramatically reduce > >>>>>> polycount on everything (and scale down the skins). Make sure the > assets > >>>>>> dir stays small, 50MB is really bad. > >>>> > >>>> I think the requirement on being power-of-two is irrelevant in the > >>>> case of Evas as we should be using Evas_GL_Image which already does > >>>> automatic packing into an atlas with the right size for us (Otherwise > >>>> we would have trouble with all the other image we load for widgets). > >>>> As for size, I agree 256x256 should be enough for this example and I > >>>> should start paying attention to file size... > >>>> > >>>>> And yeah, as Tom said, this would best go into a separate > repository. We > >>>>> don't really want this kind of stuff in efl.git. > >>>> > >>>> This I disagree. I think this is not orthogonal to efl. We are pushing > >>>> a 3d and a vector scenegraph in efl to use it for widget and > >>>> application. Showing how to use that infrastructure does make sense. > >>>> > >>>> Same actually goes with exactness data, as we are doing a graphical > >>>> toolkit and we don't have visual test in our make check. It's just a > >>>> shame and a bad excuse for not having it. If you really want that out > >>>> of the main git, I guess we could use some submodule and force make > >>>> check/examples to pull that part if necessary, but that doesn't feel > >>>> reliable at all. > >>> > >>> Submodules, as I've suggested a million times before. That's the only > >>> sane way of doing it. > >> > >> submodule only bring pain and agony to its users last time I tested > >> them. And the web is still full of complains so nothing did change > >> there, but you are welcome to enlighten me on how great they are. > > > > submodule are quite easy to use, but yeah, I guess they are a bit > > annoying for noobs. Luckily, we are not going to use them for anything > > that matters for the non technical user, we are only going to use it for > > external shit no one uses anyway. > > Seriously ? Either you never used submodule and are a complete > ignorant, or you want to inflict pain on other and cripple EFL with > problem. Everyone who used submodule will have lost commit, feel the > pain of managing a branch or rebasing work while working with others. > submodule is a sure recipe for poor quality delivered to user. Just > use google to search about all the bad experience that come out of > submodule (You don't even need to search for bad experience > specifically, just google "git submodule" and you already have on the > first page web page that explain why you should not use them...). > I've used submodules successfully for similar purposes. Stop saying bullshit. They work just fine for this kind of stuff - people get problems when they use them wrong (for example when subtree should've been used instead); for an optional repo (and examples ARE optional) it's perfectly fine and easy to manage. > > So what is your strategy to still deliver a good experience to > developers ? You know we are lacking in documentation/tests and you > are still insisting on making life harder for those trying to address > the problem... > > > The examples will still be available as another repo too, so if someone > > really wants the examples and is struggling, he can just get it directly. > > Again, we are not talking about submodules for core, we are talking > > about submodules for useless shit that's polluting our repos. > > With your definition of shit, it is going to vary from person to > person I guess. We moved to a single tree for the unique reason of > having one single synchronized release source. submodule is going to > break that for sure. And if testing the graphical result of EFL is > shit for you, let me say I kindly disagree with your wording. Same > goes with examples. The people who download EFL source are likely be > interested by a proper documentation and good examples that showcase > our technology seems like a must. > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > D5 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
