+1 to Cristian Salamea The version 6.1 has been lunched long ago and still the documentation relating web development is scarce and poor.
On Mon, Oct 22, 2012 at 4:36 PM, Ovnicraft <[email protected]> wrote: > > > On Mon, Oct 15, 2012 at 3:25 AM, Fabien Pinckaers <[email protected]> wrote: >> >> Hello Nhomar, >> >> Thanks for your feedback. My comments bellow. >> >> > Said this i proceed to describe our conclusions, because are a little >> > hard and i want to be sure it is all taken in the correct way, BUILD >> > TOGHETHER THE BEST ERP IN THE WORLD. >> >> You are right, this is the only thing that matters. >> >> All our decisions are based on what we think is the best path to achieve >> the best product ever. We sometimes do mistakes, but I think we proved >> our direction is good. (especially if you compare to all others open >> source players) >> >> Some decisions may be good to improve the product (and, thus, for future >> customers) but not as good for existing customers/partners. This is >> where we may have conflicts. OpenERP SA focus on building a great >> product but, in some situations, some community members may have reasons >> to not evolve and protect their existing situation as the change as a >> cost. (in terms of money, time or personal convictions...) >> >> Some example: >> - doing an evolution of OpenERP which is not backward compatible: it's >> good for OpenERP when it's a strong evolution, but it's bad for >> partners that developed modules based on the old model >> - stop maintaining some bad modules while refocusing to clean most >> used one. It's good for the product as the most used module will >> achieve a higher quality but not good for existing customers that >> where using the modules we do not maintain anymore. >> >> We try to limit these situations (by remaining backward compatible when >> we can) but sometimes it's not possible. Sometimes, we have to make a >> decision. >> >> To limit the disagreement of the changes due to evolution, we invested a >> lot in the OpenERP Enterprise service that helps maintaining OpenERP for >> existing customers (migrations, bugfixes, 4.5 years of warranty, ...) so >> that they are less subject to errors for the change. >> >> As an example, we will still continue to maintain the v6.0 GTK client >> for 3 years as it's guaranteed for our OpenERP Enterprise customers. >> >> > 1.- Fork GTK client is just an option if some points are covered: >> > a.- OpenERP is agreed in develop propagating the context in all them >> > 200 modules. >> > b.- OpenERP is agreed with this Fork. >> > c.- We have some kind of secure way to offer commercial support >> > between community memebrs will be in charge. >> > d.- OpenERP mantain a minimal backguard compatibility in future not >> > developing gtk client, developing @THinking@ in the existency of this >> > fork. >> >> b. Of course, we agree. We will not be against a community effort. (but >> we will not waste time on it too) >> >> In my opinion, that would be a very big mistake and waste of time. I >> seriously doubt that the community has the time to support this huge >> development and I am pretty sure that if you go into that direction, the >> GTK project will be dead in max 18 months. It's far better to join our >> efforts to make something better rather than splitting our efforts (have >> a look at what happened to Adempiere, they have 4 clients and the >> project is nearly dead as none of them was good enough) >> >> Community and partners should have better priorities like the >> localisation in all countries, porting best modules to v7.0, ... >> >> d. We will not do that. If we decided to drop the GTK client, it's >> because it became an obstacle to the evolution of OpenERP. We want >> OpenERP to evolve quickly in order to be extremely competitive on the >> market and to disrupt the ERP landscape. As I said, our priority is to >> build the best product ever, and we don't want to put obstacles to brake >> this. >> >> So, if you fork the GTK client, you should be ready to adapt everything >> by yourself and not rely on us for this as we will only focus on >> improving OpenERP. >> >> >> > 2.- From a Commercial PoV, i think we are chetting with this decition to >> > our customers, in the last Partner Days, Fabien explicitly said they >> > will not stop mantain GTK client, in 6 month he change his mind, What >> > will i say to my customers? that they will need invest X thousand dollar >> > in re-train +1000 users? if i was SaP it should be for me a good news, >> > but we are not, this kind of moves are the ones make us move from >> > privative to Open solutions 12 years ago. >> >> I apologize as I changed my mind during the v7.0 development. I changed >> my mind because it's better for OpenERP. >> >> The problem with v7.0 is that the required effort is much more than just >> maintaining the GTK client. I was ready to maintain the GTK but OpenERP >> evolved so much in v7.0 that the effort is not just maintaining it. In >> order to make it clean, it requires a full evolution which is a much >> higher effort. >> >> As we don't have unlimited resources, we had to choose between two >> solutions: >> - develop two client which are both half clean >> - focus on one client but make it super clean >> We chose the second option. (and I hope the community will follow as >> it's better to join our efforts rather than splitting it) >> >> Don't forget that we continue to maintain GTK for your v6.0 customers. >> >> Also, the GTK/Rich technology started to become a strong constraint that >> slow down the evolution of OpenERP: >> - Available open source libs are very limited in Python/GTK compared >> to javascript (gantt charts, many2many_tags, kanban, OAUth >> authentification, LinkedIn API, ...) >> - The GTK client is based on a quite old code base and requires a >> complete rewrite to make it clean. >> - Modularity is key for OpenERP. Having modules for the UI is not >> just an extra feature. Don't forget that the success of OpenERP is >> due to his modularity; we need the same power for the UI to ensure >> the success of OpenERP in the long term. >> >> >> > 3.- From the technical PoV, is really hard mantain both clients, but >> > this is basically because the leak of openess in some dev process and >> > the leak of SQA, i mean, Today, we have process that don't pass >> > correctly the context (Unique way to work with both clients), and it >> > brings a lot of problems, other thing is, the leak of central processing >> > related to workflows, a lot of thing are hard written and avoid a real >> > centralized part with the business objects, but BTW other history >> > problem. >> >> The complexity is in the changes, not in the openness. >> >> The main issue is that OpenERP still need to evolve quickly to reach a >> much higher quality. I understand that these changes are complex for the >> contributors. But these changes are also critical for the success of >> OpenERP in the long term. >> >> If OpenERP is today the best ERP ever, that's because we evolved very >> quickly. We need to maintain this rythm to transform the ERP landscape. >> >> > 4.- I think one of our BEST approach is the fact of have 2 Official >> > CLIENTS, that allow customers have the good part of both worlds (desktop >> > and Web), today all our cleints use both clients, because they are good >> > for @different things@. >> >> Yes, this is today. But tomorrow, everyone will use and prefer the web >> client as it is much better. >> >> Seriously, I do not see any advantage on the GTK client that can not be >> done easily in the web one. May be today it's not perfect but it's just >> a matter of weeks/months. >> >> >> > 5.- About Backguard Compatibility, at least today, we have 2 years to >> > migrate customers to 7.0, it must not be done tomorrow, we have 2 years >> > to convince them that Web is better, BUT, @fabien read very well, This >> > desition is TAKING OFF 50% of usability of OpenERP, 50% of useability, >> > already supported by an OpW, im not talking about community, Our >> > cutomers bought an OPW for Security, Migration and Stability, not to >> > lose 50% of funcionability, and then we must send our Salesman and >> > ourself to convince them that Web is Good. IMHO They Buy Support and >> > Warranty for 2 clients NOT ONE, How do i discuss this argument my >> > friend? (already said by 2 of my customers). >> >> I bet your customers will ask to use the web client as it's simply much >> better in every aspects. >> >> > 6.- About the agument "We prefer mantain 1 very well than 2 bad", Ok, Im >> > agreed, and i respect this Point of view, but the real situation is that >> > you dont have 1 very well, because, the real fact is that we dont have a >> > lot of funcinalities that we had in v6.1 >> >> I don't think so. Some feature may be missing but they are easily >> developed as a module. (like tabs) >> >> > I think we need some features ABSOLUTLY NECESARIES in V7.0 if desition >> > is taken to be able to deploy correctly transition. >> > 1.- Menus ala admin menu (Already in v6.1) we use A LOT this feature: >> > http://drupal.org/files/images/Administration-menu.png >> > 2.- Copy and paste to use tree information on a spreadsheet, it can be >> > solve easyly if we include this feature (not with excel with direct >> > csv). >> > You can implement freely as you think is te correct way, but it can >> > replace the copy-paste just neede to quickly pass to excel y/0 OO. >> > >> > http://planet.domsense.com/en/2012/06/openerp-how-to-export-current-tree-view-to-xls-use-web_export_view/ >> > 3.- Print Screen in PDF, Priority 1. >> > 4.- Print Workflow in PDF, Priority 1. >> > 5.- I have a question: how do replace the easy way you pass with @Tab@ >> > key without loss layout in web?, this is important too! >> > 6.- ShortCuts, Priority 1. >> > 7.- MultiTabs. PLEASE dont ask me develop by myself, i have already this >> > in GTK and is your desition take off. >> > 8.- Test the posibility of use ALL the web client without mouse. When it >> > should be possible, you will think IT IS READY!, after impossible, think >> > in people loading thousand of records per day, not just in new ones that >> > will learn quickly. >> > 9.- If you decide just not mantain, create yourselve the fork and put a >> > copy with openerp-gtk-drivers permisions to make it official, give us >> > the power, but i think it is a bad move. >> >> 1. This is very easy in web. (but requires a bigger develoment in GTK) >> 2. probably a 100 lines patch/module for the web client >> 3. The printscreen is better in web as it works for everything now, >> including form views. It uses an @media css through the native >> printing of the browser. You can also implement the old printscreen >> which is probably a 100 lines patch/module for the web client >> 4. Already implemented in the debug mode >> 5. don't understand your question; tabs are the same in web and GTK ? >> 6. Already implemented >> 7. We made breadcrum which is an alternative. If you need tabs, a >> module is just 100 lines of code. >> 8. Shortcuts are quite easy to implement in web >> >> So, I don't see any reason why we need a GTK. Porting those features to >> the web is probably a 10 days effort while making the GTK evolve is >> probably a 30 man*months effort. > > > > Hello @Fabien, in Gnuthink we are totally agree to just support Web, but as > i wrote in a mail before, please we need a better technical documentation, > if Partners & community get this everything will be easiest. Its more fast > include a new developer to read doc instead read the code (thinking in > time), so partners and community needs start to migrate modules. > > For all partners an community, we can does better Web development, from > company side is more fast get web developers instead gtk developers and grow > faster. > > Best regards, >> >> >> -- >> Fabien Pinckaers >> CEO OpenERP >> Chaussée de Namur 40 >> B-1367 Grand-Rosière >> Belgium >> Phone: +32.81.81.37.00 >> Fax: +32.81.73.35.01 >> Web: http://openerp.com >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp > > > > > -- > Cristian Salamea > @ovnicraft > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
