Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 11, 2013, at 10:53 AM, Phil Longstaff wrote:
> John,
>
> what's your view of the best way forward? I'm confused by what you want to
> wrap C++ inside GObject. What's your end vision and what are the steps along
> the way.
>
The goal is, as ever, a clean, modern architecture with fewer dependencies.
Christian wrote at length last year about how our core library isn't portable
because it depends heavily upon Glib. Until that discussion, I'd thought of
that as a feature, because GLib provides so many services. But it does tie us
to the Gnome ecosystem -- and to MinGW for M$Windows. Plus, it's a lot of work
to write GObject code, and when you're done it's hard to understand compared to
a proper OO language. Derek's bringing up abandoning Gtk+ popped that out
I don't really want to wrap C++ in GObject, but I'd prefer to incrementally
change the engine and backends to C++, because writing GObject stuff is such a
PITA. The current design has a shallow class tree: Everything derives from
QofInstance. But it's also a bit tangled, with the different classes being
badly interdependent. It would be safer to convert one class at a time to C++,
starting with QofInstance, but doing so requires GObject classes to be able to
derive from a C++ class. The reverse has already been worked out, because
that's how the various OO language bindings for Gtk+ and friends work. That's
what the reference to glibmm is about.
On Feb 11, 2013, at 1:21 PM, Christian Stimming wrote:
>
> Have a look at the existing cutecash code: In
> src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see
> there, the module has a gnc::GncInstance base class that wraps the
> QofInstance
> "object" that manages the qof parts. This in turn is derived from
> Glib::Object
> which is the C++ version of a GObject. In my opinion, this wrapping of
> GObject and also (while it still exists) QofInstance in the end looks very
> well possible and the resulting C++ classes look well enough like a real C++
> class.
Thanks for the pointer. Having a concrete example will be helpful.
What I was thinking was that I'd want to rewrite QofInstance in C++ and then
derive Account and friends from it while leaving them as GObjects. As I started
to write about that I realized that we don't actually use the virtualization
features of GObject, we just manually chain up the superclass functions where
we need them, so it's not really a problem. A header full of inline functions
to translate those chaining-up functions will do the trick.
For example:
inline QofBook* qof_instance_get_book (gpointer inst)
{
return static_cast(inst)->get_book();
}
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6
On Feb 11, 2013, at 11:41 AM, David Carlson wrote: > On 2/11/2013 12:21 PM, Derek Atkins wrote: >> David, >> >> David Carlson writes: >> >>> Also please keep in mind your goals regarding database filetypes. >> I have no idea what this means in terms of the existing discussion. >> Being able to have multi-user support has nothing to do with "database >> filetypes". It's completely about change-notification, client-side >> caching, and cache coherency. >> >>> David C >> -derek >> > So all your discussion about C++ , GTK this and that would not change if > you were planning to drive a database engine with a lot of relationships > defined by a database structure as opposed to hard coding all data > relationships. Or maybe you are planning to but just haven't said so in > any of the emails that I read. Or maybe all of your code modules have > such clean, well structured input and output interfaces that they can be > used either way. > > Tell me that change-notification, client-side caching, and cache > coherency occupy such a large part of your development time that overall > program structure is immaterial. > > I thought that knowing whether or not this is a goal might be an > opportunity to reduce the development time since you already have a good > start on database development. Well, we can save a Gnucash data set to a SQL database and read it back. That's not the same as actually using the database for querying, which we don't do. You actually cut to the heart of the problem with > Or maybe all of your code modules have > such clean, well structured input and output interfaces that they can be > used either way. Nothing could be further from reality, and cleaning that up is a prerequisite for progress towards using a database backend in a way that would enable simultaneous multi-user access. This discussion about C++ vs. GObject is about how best to accomplish that cleanup. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
* would recommend writing C++ header files as a starting point tedc * On Mon, Feb 11, 2013 at 1:21 PM, Christian Stimming wrote: > Am Montag, 11. Februar 2013, 10:36:31 schrieb John Ralls: > > > I was just pointing out that if we had to spend a lot of time migrating > > > to Gtk3 we might be better off spending the time migrating to something > > > else. > > > > OK. In fact we've (meaning Geert's) already done 90% of the job. All > that's > > left is fixing the register to draw with Cairo surfaces instead of the > > ancient libgnome stuff. Not an easy job, but much easier than porting > > everything to Qt. > > Very good. > > > > I still wish I had written QOF in C++ instead of C a decade ago. :-( > > > > Me too. But that's not too hard to fix, once I figure out how to get > GObject > > to inherit from a C++ object. The answer is no doubt somewhere in glibmm. > > But it's not quite time for that yet. > > Have a look at the existing cutecash code: In > src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you > see > there, the module has a gnc::GncInstance base class that wraps the > QofInstance > "object" that manages the qof parts. This in turn is derived from > Glib::Object > which is the C++ version of a GObject. In my opinion, this wrapping of > GObject and also (while it still exists) QofInstance in the end looks very > well possible and the resulting C++ classes look well enough like a real > C++ > class. > > Disclaimer for all other readers: The C++ part of this discussion is > currently > only an academic one. It has not yet anything to do with the real work > that is > done in the coming months. > > Regards, > > Christian > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
Am Montag, 11. Februar 2013, 10:36:31 schrieb John Ralls: > > I was just pointing out that if we had to spend a lot of time migrating > > to Gtk3 we might be better off spending the time migrating to something > > else. > > OK. In fact we've (meaning Geert's) already done 90% of the job. All that's > left is fixing the register to draw with Cairo surfaces instead of the > ancient libgnome stuff. Not an easy job, but much easier than porting > everything to Qt. Very good. > > I still wish I had written QOF in C++ instead of C a decade ago. :-( > > Me too. But that's not too hard to fix, once I figure out how to get GObject > to inherit from a C++ object. The answer is no doubt somewhere in glibmm. > But it's not quite time for that yet. Have a look at the existing cutecash code: In src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see there, the module has a gnc::GncInstance base class that wraps the QofInstance "object" that manages the qof parts. This in turn is derived from Glib::Object which is the C++ version of a GObject. In my opinion, this wrapping of GObject and also (while it still exists) QofInstance in the end looks very well possible and the resulting C++ classes look well enough like a real C++ class. Disclaimer for all other readers: The C++ part of this discussion is currently only an academic one. It has not yet anything to do with the real work that is done in the coming months. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6
On 2/11/2013 12:21 PM, Derek Atkins wrote: > David, > > David Carlson writes: > >> Also please keep in mind your goals regarding database filetypes. > I have no idea what this means in terms of the existing discussion. > Being able to have multi-user support has nothing to do with "database > filetypes". It's completely about change-notification, client-side > caching, and cache coherency. > >> David C > -derek > So all your discussion about C++ , GTK this and that would not change if you were planning to drive a database engine with a lot of relationships defined by a database structure as opposed to hard coding all data relationships. Or maybe you are planning to but just haven't said so in any of the emails that I read. Or maybe all of your code modules have such clean, well structured input and output interfaces that they can be used either way. Tell me that change-notification, client-side caching, and cache coherency occupy such a large part of your development time that overall program structure is immaterial. I thought that knowing whether or not this is a goal might be an opportunity to reduce the development time since you already have a good start on database development. David C 0xDC7C8BF3.asc Description: application/pgp-keys ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
John, what's your view of the best way forward? I'm confused by what you want to wrap C++ inside GObject. What's your end vision and what are the steps along the way. Phil From: John Ralls To: Derek Atkins Cc: "gnucash-devel@gnucash.org Devel" Sent: Monday, February 11, 2013 1:36:31 PM Subject: Re: Beyond 2.6 (was:Re: Gnucash 2.5/6) On Feb 11, 2013, at 10:23 AM, Derek Atkins wrote: > John Ralls writes: > >>> As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're >>> dumping Gtk+ because we don't like the direction they're going, Gtkmm >>> doesn't get us anywhere. >> >> Having argued that C++ in the backend in not such a big deal, I'm >> going to turn around and point out that dropping Gtk+ in favor of wx, >> Qt, or some other GUI framework isn't a easy job: That *is* a complete >> rewrite, and there's a lot of it. >> >> Who would do it? > > I was just pointing out that if we had to spend a lot of time migrating > to Gtk3 we might be better off spending the time migrating to something > else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. > > I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 11, 2013, at 10:23 AM, Derek Atkins wrote: > John Ralls writes: > >>> As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're >>> dumping Gtk+ because we don't like the direction they're going, Gtkmm >>> doesn't get us anywhere. >> >> Having argued that C++ in the backend in not such a big deal, I'm >> going to turn around and point out that dropping Gtk+ in favor of wx, >> Qt, or some other GUI framework isn't a easy job: That *is* a complete >> rewrite, and there's a lot of it. >> >> Who would do it? > > I was just pointing out that if we had to spend a lot of time migrating > to Gtk3 we might be better off spending the time migrating to something > else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. > > I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
John Ralls writes: >> As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're >> dumping Gtk+ because we don't like the direction they're going, Gtkmm >> doesn't get us anywhere. > > Having argued that C++ in the backend in not such a big deal, I'm > going to turn around and point out that dropping Gtk+ in favor of wx, > Qt, or some other GUI framework isn't a easy job: That *is* a complete > rewrite, and there's a lot of it. > > Who would do it? I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. I still wish I had written QOF in C++ instead of C a decade ago. :-( > Regards, > John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6
David, David Carlson writes: > Also please keep in mind your goals regarding database filetypes. I have no idea what this means in terms of the existing discussion. Being able to have multi-user support has nothing to do with "database filetypes". It's completely about change-notification, client-side caching, and cache coherency. > David C -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
John Ralls writes: > The target milestone is actually intended for *open* bugs, to create a > "roadmap" report which lists all of the bugs which are supposed to be > fixed before a particular release. Although we've also used it to mark the release in which a bug was fixed. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
Thanks From: Robert Fewell <14ubo...@gmail.com> To: gnucash-devel@gnucash.org Sent: Monday, February 11, 2013 10:40:27 AM Subject: Gnucash 2.5/6 Phil, I may of misunderstood, the csv transaction importer use two tree-views one above each other and keeps the columns in sync. Have a look in assistant-csv-trans-import.c Regards, Robert. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash 2.5/6
Phil, I may of misunderstood, the csv transaction importer use two tree-views one above each other and keeps the columns in sync. Have a look in assistant-csv-trans-import.c Regards, Robert. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
Yes. I have a first draft ready to go. Looks pretty rough but is usable, which is what I needed. What I've done: 1) structurally, split GncBudgetView out from GncPluginPageBudget. GncBudgetView provides a widget that GncPluginPageBudget can use and configure. 2) modified GncBudgetView so that if a budget cell belongs to an account which has children, but does not have a value of its own, it displays the sum of its children's budget values in gray. Provides a row of totals. 3) added a col called "totals" which sums the values for each row and provides a total for the year (assuming a 12-month budget) 4) added a section below the main budget with 4 lines: a) income - duplicates the values from the top level income account b) expenses - duplicates the values from the top level expense account c) transfers - top level assets values - top level liabilities values d) total = income - expenses - transfers. Red if negative Basically these changes provide some totals and summary values. I'd really like the columns in the lower display to line up with those in the upper display, but haven't figured that out yet. I'd like the account name and totals column to be fixed, and any scrolling to happen with the budget period figures, but haven't figured that out yet. I could make the totals column a separate tree view outside the main tree view, but would then need to make it expand and contract along with the main tree view. Basically, I'm trying to learn the gtk widgets and make a good display. If anyone is a gtk expert and wants to give me some pointers, that would be great. I was trying to set up git and locked myself out of svn, so I'm unable to commit anything at this point. I want to do a bit more cleanup, but should have something by next weekend. Phil From: Geert Janssens To: gnucash-devel@gnucash.org Sent: Saturday, February 9, 2013 12:03:44 PM Subject: Re: Gnucash 2.5/6 On 09-02-13 00:59, Phil Longstaff wrote: > At this point, there's an itch which is bothering me more and it's in the > budgeting area. I'm separating the budget plugin page into the page and the > budget display widget so I can enhance the widget by adding more info. I > want a fixed "total" column, and fixed "income", "expense" and "transfers" > rows (transfers = transfers to assets or liabilities). > > GSettings is taking second place to that. > > Phil > > Thanks for clearing that out. Of course you are free work on what you feel like to be more important to you. Do you want the improvements in the budgetting area included in 2.6 ? I mean do you want us to postpone the feature freeze until you get a first draft of the improvements in trunk ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
