2011/12/21 Carsten Haitzler <[email protected]>: > On Wed, 21 Dec 2011 11:44:29 +0900 Bluezery <[email protected]> said: > >> 2011/12/20 Tom Hacohen <[email protected]>: >> > On 20/12/11 12:27, Carsten Haitzler (The Rasterman) wrote: >> >> agreed. programmer should simply try and use pinch gestures and if he >> >> doesnt get any either its not possible (no multi-touch device) or, no >> >> emulated gesture/input is being used (he really is looking at zoom not >> >> pinch so you can emulate with mousehweels etc. or other actions like >> >> "double tap" and so on). the programmer shouldn't decide by system >> >> configuration decides - if someone wishes to violate the patent by turning >> >> it on, they can, but otherwise it's off by default. in theory we maybe >> >> should also shoudl be able to compile out the code to handle the bevhavior >> >> which at the app level will result in the same thing as it being off in >> >> config - it just can never be turned on without a recompile (freetype did >> >> this with bytecode hinting for many years). >> > >> > Yep, freetype is the same example I had in mind. >> > >> >> Thank you for your comments. :) >> Besides, I have a question. >> I know that bytecode interpreter was patented previously and It was >> disabled at compile time in Freetype. >> If so, bytecode interpreter was not included in released Freetype binary??? >> But elm_gesutre is built in when elementary binary is released and it >> can be disabled at runtime time. > > well freetype offered just the compile-time switch. runtime the app requested > which kind of hinting they wanted via an api. as such efl always requested > bytecode, BUT if freetype didn't have bytecode hinting it would fall back i > think to autohinting. that patent has now expired so it's not relevant > anymore, > but taking it as an example many linux distributions disabled bytecode hinting > entirely. others kept it enabled BUt configured everything by default to not > use it (use auto hinting). this seems to have worked quite well so far. > > another thing that came to mind is... make the behavior pluggable. yes - it's > a > "workaround" but this is the same workaround linux distros use for mp3. don't > ship with any mp3 codecs, but users can add them later themselves from "3rd > party packages". as such the vendor doesnt violate any patent. someone making > a > module to recognize pinch "events" and pass out some zoom events is probably > not violating a patent as the patent probably covers a much wider pipeline and > such a module is simply translating/interpreting events. even if it violates, > it is just this 3rd party module that violates, not the system that it plugs > into. > > so my advice to do this best is: > > 1. allow it to be compiled out OR even better - make it a module. > 2. if you make a module, make sure that it can be built totally separately as > a > stand-alone piece of software. > 3. allow the module configuration to be able to bring it in and then enable > the > feature *IF* a user installs the module and changes that config > 4. leave it to "3rd parties" to make such a tool or package that does that - > if > they want. you just made it possible to do that and have an example. :) > >> Does this have no problems?? Anyway, I hate damn patent :-(. > > welcome to the club. :)
Thank you for your advice. Compiled out and pluggable which user can add/remove easily may be the best solution. But it have much to do :-&. Patent issues related pinch gestures are not clear yet. So it will enter the todo list. :p -- BRs, Kim. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
