Re: QtMoko and FSO (was: qtmoko v33)
Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support- most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop:( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. +1 Absolutely. -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
+1. I've only recently switched from SHR to qtmoko (v31) and I'm impressed with performance and maturity of applications. I really wouldn't like to lose that again. Regards Bernhard Am Donnerstag, den 10.03.2011, 12:00 +0100 schrieb community-requ...@lists.openmoko.org: Von: Gennady Kupava g...@bsdmn.com Reply-to: List for Openmoko community discussion community@lists.openmoko.org An: List for Openmoko community discussion community@lists.openmoko.org Betreff: Re: QtMoko and FSO (was: qtmoko v33) Datum: Wed, 09 Mar 2011 22:48:28 +0300 (2011-03-09 20:48:28) Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Gennady Kupava, Mar. 09, 2011, 22:48 +0300: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort OK, I'd like to ask one question now. Is there a reasonable technical way to *control* qt-stack-managed Freerunner without GUI? This means sending SMS from CLI and all these small things. In other words, I'm interested in command-line interface instead of programming interface. I believe the latter is up and running, but is the former implemented? Frankly, I do not know what the answer is. And yes, in case it is like You just invoke this function from this library with proper arguments, I think I'll go and write a simple CLI wrapper, for this is just what makes Unix-like systems so usable. But if the only correct implementation lives deep in the code of qt stack, then we'd better try and separate it. Generally speaking, I guess it's convenient and powerful interfaces, rather than compatibility with existing applications, that matter more just here. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Agree with Gennady. Look what happened to SHR! It is also necessary to fix rndis usb-host ) On Wed, 09 Mar 2011 22:48:28 +0300, Gennady Kupava wrote: Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko and FSO (was: qtmoko v33)
Radek Polak, Mar. 04, 2011, 07:37 +0100: i have uploaded new qtmoko v33 images to sourceforge now [1]. [...] The list is quite short on how much of work it was. Hello, Radek! Thank you for the work you are doing. Most of the effort was to package everything with debian package system. This should be done now except for kernel which is on the list for next release. [...] My plan for next version is to fix regression if you find any, package properly also kernel and release it as stable. Plans for future is FSO framework in qtmoko. I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Thanks once more. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
