On Wed, 21 Dec 2011 14:06:27 +0900 Bluezery <ohpo...@gmail.com> said:
> 2011/12/21 Carsten Haitzler <ras...@rasterman.com>: > > On Wed, 21 Dec 2011 11:44:29 +0900 Bluezery <ohpo...@gmail.com> said: > > > >> 2011/12/20 Tom Hacohen <tom.haco...@partner.samsung.com>: > >> > 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 ok! :) this is the kind of hurt/hell patents cause. :( -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
