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. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
