Hi Tobias, thanks for the interesting work on the gnucash application! I've seen the other replies here, but I would like to add some remarks to your proposals with a somewhat different direction:
Am Sonntag, 21. Februar 2016, 20:12:58 schrieb Tobias Markus: > While I got GnuCash pretty much working under GTK+ 3, a lot of further > (fundamental and architectural) changes are required before even > thinking about a release. Simply spoken, we now have GnuCash working in > GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go > down this path, the user experience will be substandard, especially > compared to the current releases. I think it is great to get some sort of gnucash to run under a more up-to-date UI toolkit. I think gtk2 is very much a dead-end, let alone those various custom widgets inside gnucash that are even older. However, only very little effort is being spent here to switch to a different toolkit. My guess is that UI developers who work with modern UI toolkits have long abandoned on gnucash development anyway... but that's just my opinion. > A quick word on dependencies: I set the minimum GTK+ version to be 3.18 > because I didn't try to compile it with any earlier versions, but > backporting probably isn't too hard. In my opinion a switch to a new toolkit will be a radical step anyway, so feel free to pick as new a version as is convenient to the developers involved. > Major stuff not yet migrated: > * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2. > I have not yet looked into this. Yes, that would need some additional effort, because the UI calls that are needed in the online banking code (of aqbanking) need some UI abstraction and its author decided to implement his own abstraction, resulting in the gwenhywfar UI structures. The gwenhywfar UI abstraction has implementations for gtk2, qt4, qt5. For gtk3 "somebody" will have to port the existing code there to gtk3, too... I can't tell whether any developer here will volunteer for this. > Things that I recommend be dropped/removed for GnuCash 3.0: > * Maintaining both the CMake and autotools-based build system does not > seem like a good idea, so drop autotools. Yes, absolutely. Autotools has been a pain in the neck for everyone here way too long. I'm all for dropping it altogether, the sooner the better. > * Rewriting the old register is not really viable or useful, > so drop it. Currently, either the old or the new register is compiled > to ease transition. (Right now, the new register can be enabled in > addition to the old register.) Yes, switching to register2 or whatever the more up-to-date version is called should also happen better sooner than later. However, this will mean a new version will not be as feature-complete as the previous version. I doubt whether this is a good goal in any case. Maybe we should be courageous enough to just call the old gtk2 code a dead end, including all of its beloved features here and there, and just say we will spend our development time only in new modern code. > * The dynamic module system (based on GModule) is a nice idea, but the > benefits are dubious at the moment. While the dynamic loading of all > the standard modules incurs a heavy startup delay, there is no > reason why a user would not want to load all the built-in modules. Although most of the current modules are used always and hence better linked in statically, there is still some benefit from the module system: Parts of our features imply an additional large dependency tree, e.g. aqbanking, or postgresql. Making them a module will enable distributions to package them in separate packages, so that users will need the aqbanking dependencies only if they install the gnucash-aqbanking module, or for postgresql the same. Hence, I think gnucash should keep some sort of plugin system in any case. However, currently due to guile's module loading we have additional requirements on the way modules are used. Others here can explain this better for sure. > Major Changes that I highly recommend for a GnuCash 3.0 release: > * Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome > and boilerplate-ish process. Vala makes it possible to write GObject > code in a very concise way I agree whole-heartedly that writing UI code in C sucks, royally. For me this has been the major reason to keep away from further gnucash development, unless I needed some feature myself really badly. I mean, we have 2016. UI programming should be done in some programming language that is good for this job. C is not. Pretty much any other high-level programming language will do a better job here. I don't know Vala so far and I can't judge whether the benefits will outweigh enough the (presumed) rather small user base. C++, C#/Mono, or Java are known to me and would do the job well enough, but other languages are fine, too. Just get away from C w.r.t. UI programming. As a side note, this might mean the Android App "gnucash-on-android" has a huge advantage over the conventional desktop application in that it uses an up-to-date programming language. Maybe some time down the road the Android app will start to take over the desktop usage of gnucash as well... but that's a different discussion. > UI Design Notes: > > The current UI has the menubar as the central element. Depending on > which "plugin page" you're currently looking at, certain menus are > shown or hidden, (...) > Both the heavy usage of menus and the context-sensitive visibility of > menus are discouraged by the Gnome 3 HIG. A more modern UI design would > greatly benefit the GnuCash user experience. I agree with the statement in general, but I'm not convinced the Gnome 3 HIG is a goal I would commit to. As you have read in the other replies, others have their doubts about the Gnome 3 HIG as a wortwhile goal, too. On the other hand, using just about any HIG will surely improve the usability of gnucash just by having more consistency and listening to the thoughts that went into the creation of the HIG. So maybe the Gnome3 HIG isn't such a bad choice. But as you already saw the choice is currently far from being agreed upon. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
