Are There Plans For A GUI Overhaul?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Are There Plans For A GUI Overhaul?

Linux Luser
I've been doing my personal finances using spreadsheets for many years now.
I've gotten things down where it's easy now. However, it's hard to get good
data out of it. I needed a real financial program so I turned to gnucash. I
am happy I did. It was challenging to have to learn good accounting
practices, terminology and approaches to finances. The learning experience
itself was worth it and I now feel I can utilize gnucash for my financial
needs.  Thanks a lot to all who've contributed!


Now I have concerns of a technical nature. I have run into so many
usability bugs in the application that I've lost track. I thought, "I'll
see if there's a bug open for this or maybe open a new one." I've even
thought "Well, time learn C again!" I looked through the bug queue and
noticed that lots of the GUI-related bugs were years old. Even things that
should be simple to fix.

In the code I found out about cutecash, a QT-based GUI for gnucash. I ran
into lots of build problems on my machine that I haven't resolved yet (does
it still build?), so I was unable to see it first hand.

However, all of this, taken together, has lead me to believe that gnucash
is due for a GUI transplant. It needs a makeover, if only for the
developer's sake so that it's easy to fix usability bugs qiuckly (which
appears not to be the current case).


What are the current discussions surrounding build a new, modern GUI for
gnucash? Has there been talk about using a different language, other than
C/C++ for the GUI? QT or GTK3?

And to expose my biases a little, my experience is mostly with Python.
Python + Glade has worked well in the past for to create a GUI in a
surprisingly small amount of time. I also use Python at work for mostly
data-related tasks so I know how easy it is do some very cool data work in
Python. Most meta-type of programming can be done well using dictionaries!


I'm wanted to get my feet wet and help, but I feel like trying to work out
all of the GUI problems with the current build of gnucash would be futile.
It seems to me that if a new language/toolkit combo could be found that
most current developers could agree upon, then it would re-ignite interest
in gnucash's usability.



Thanks,
Dave
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 4, 2016, at 6:42 AM, Linux Luser <[hidden email]> wrote:
>
> I've been doing my personal finances using spreadsheets for many years now.
> I've gotten things down where it's easy now. However, it's hard to get good
> data out of it. I needed a real financial program so I turned to gnucash. I
> am happy I did. It was challenging to have to learn good accounting
> practices, terminology and approaches to finances. The learning experience
> itself was worth it and I now feel I can utilize gnucash for my financial
> needs.  Thanks a lot to all who've contributed!
>
>
> Now I have concerns of a technical nature. I have run into so many
> usability bugs in the application that I've lost track. I thought, "I'll
> see if there's a bug open for this or maybe open a new one." I've even
> thought "Well, time learn C again!" I looked through the bug queue and
> noticed that lots of the GUI-related bugs were years old. Even things that
> should be simple to fix.
>
> In the code I found out about cutecash, a QT-based GUI for gnucash. I ran
> into lots of build problems on my machine that I haven't resolved yet (does
> it still build?), so I was unable to see it first hand.
>
> However, all of this, taken together, has lead me to believe that gnucash
> is due for a GUI transplant. It needs a makeover, if only for the
> developer's sake so that it's easy to fix usability bugs qiuckly (which
> appears not to be the current case).
>
>
> What are the current discussions surrounding build a new, modern GUI for
> gnucash? Has there been talk about using a different language, other than
> C/C++ for the GUI? QT or GTK3?
>
> And to expose my biases a little, my experience is mostly with Python.
> Python + Glade has worked well in the past for to create a GUI in a
> surprisingly small amount of time. I also use Python at work for mostly
> data-related tasks so I know how easy it is do some very cool data work in
> Python. Most meta-type of programming can be done well using dictionaries!
>
>
> I'm wanted to get my feet wet and help, but I feel like trying to work out
> all of the GUI problems with the current build of gnucash would be futile.
> It seems to me that if a new language/toolkit combo could be found that
> most current developers could agree upon, then it would re-ignite interest
> in gnucash's usability.

Dave,

Thanks for your interest, and especially thanks for asking before starting to work!

The current GUI is indeed a bit tired, but we're blocked from making substantial changes to it by two problems with the code. The more significant is that there's a lot of "business logic" inside of the GUI code coupled rather tightly with Gtk2. That needs to be extracted to break the coupling and to make it available to alternative GUI frameworks. The other problem is that the core of the GUI, the register, was lifted from gnumeric 15 years ago and has its own list view that was a precursor to GtkTreeView for Gtk+-2.0. Bob Fewell rewrote a Gtk+-2.24 GtkTreeView replacement (you'll see it in the code base as "Register2" but he wasn't able to get it stable in time for 2.6 and hasn't pursued it since because we still don't know for the long term what toolkit we want to use and he feels that any work on Register2 might be thrown away.

Around the time that we started discussing a new GUI we also realized that our core library is tightly bound to Gtk+ through the extensive use of GLib and GObject. We need to break that dependency in order to be able to use non-Gtk GUIs and to port GnuCash to mobile platforms. Geert and I have prioritized rewriting the core in C++ for the current and next development cycles (i.e. through 2020).

There's one other core item on the agenda: Removing Scheme from everything except the report system. We haven't made any progress at all on that.

There are no plans at all to use a language other than C++ for new work in the near term. Once those three projects are completed we'll be in a position to write Android (in Java, the only choice) and iOS (Swift or Objective-C, again the only choices) as well as whatever we decide upon for the desktop GUI. Python isn't likely to be a choice: There are no native Python GUIs, only Python wrappers of varying quality (merely OK to abysmal) around C and C++ frameworks, and modern C++ is just as expressive as Python without the burden of garbage collection and portability problems for the wrappers.

Regards,
John Ralls





_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Geert Janssens-4
In reply to this post by Linux Luser
On Monday 03 October 2016 21:42:54 Linux Luser wrote:

> I've been doing my personal finances using spreadsheets for many years
> now. I've gotten things down where it's easy now. However, it's hard
> to get good data out of it. I needed a real financial program so I
> turned to gnucash. I am happy I did. It was challenging to have to
> learn good accounting practices, terminology and approaches to
> finances. The learning experience itself was worth it and I now feel
> I can utilize gnucash for my financial needs.  Thanks a lot to all
> who've contributed!
>
>
> Now I have concerns of a technical nature. I have run into so many
> usability bugs in the application that I've lost track. I thought,
> "I'll see if there's a bug open for this or maybe open a new one."
> I've even thought "Well, time learn C again!" I looked through the
> bug queue and noticed that lots of the GUI-related bugs were years
> old. Even things that should be simple to fix.
>
> In the code I found out about cutecash, a QT-based GUI for gnucash. I
> ran into lots of build problems on my machine that I haven't resolved
> yet (does it still build?), so I was unable to see it first hand.
>
> However, all of this, taken together, has lead me to believe that
> gnucash is due for a GUI transplant. It needs a makeover, if only for
> the developer's sake so that it's easy to fix usability bugs qiuckly
> (which appears not to be the current case).
>
>
> What are the current discussions surrounding build a new, modern GUI
> for gnucash? Has there been talk about using a different language,
> other than C/C++ for the GUI? QT or GTK3?
>
> And to expose my biases a little, my experience is mostly with Python.
> Python + Glade has worked well in the past for to create a GUI in a
> surprisingly small amount of time. I also use Python at work for
> mostly data-related tasks so I know how easy it is do some very cool
> data work in Python. Most meta-type of programming can be done well
> using dictionaries!
>
>
> I'm wanted to get my feet wet and help, but I feel like trying to work
> out all of the GUI problems with the current build of gnucash would
> be futile. It seems to me that if a new language/toolkit combo could
> be found that most current developers could agree upon, then it would
> re-ignite interest in gnucash's usability.

Hi Dave,

I'm pleased you are interested in an better user experience for GnuCash.
It's one of the things I care a lot about as well.

This has been discussed in the past a couple of times, but we never got
to a conclusive decision.

What is clear is that a gui overhaul is needed and will eventually
happen. It's currently not a priority though. The currently active
developers have decided to first refactor the non-gui parts of gnucash.
We're in the middle of a transition from C to C++, aiming for easier to
manage code with better abstraction and encapsulation and - more related
to this thread - a better separation of functionality and gui.

As this rewrite makes the non-gui code quite a moving target it was more
or less decided to postpone the gui rewrite to later. Too many moving
targets are too difficult to keep track of.

The choice as C++ as our base language also makes Gtk less attractive as
GUI toolkit to continue with in the long term. There are C++ bindings
for Gtk, but overall it's not a very good match.

In addition the multi-platform nature of gnucash further limits the
possible choices of GUI toolkit.

In particular your suggestion to do the gui in python + glade is
currently not an option as we don't have python integration available on
our Windows or OS X ports. This has been tried in the past, but so far
it wasn't successfully implemented.

Taking all restrictions together, the last discussions in the passed
proposed two potential candidates to become the new gui toolkit for
gnucash: Qt and WxWidgets.

This brings us to cutecash as well, which was an experiment by one of
the developers to see if it was feasible to use the gnucash business
logic with a new gui toolkit (qt). While the experiment in itself could
be considered successful it never was developed further into a fully
fledged replacement gui for gnucash. The experiment did expose several
issues with the business logic and hence was an indirect trigger for the
rewrite that's currently going on.

Considering the limited manpower we currently have, it will still take a
few years before we get to really replacing the current GUI. This
doesn't mean however I'm not welcoming patches for the current GUI as
well if they fix small usability issues. And I personally think we may
have to finish the port to Gtk3 even before we get to porting a new
toolkit. Gtk2 may not be supported long enough for us to be able to make
the transition.

There are two things holding back that switch to Gtk3:
1. our register code, which is based on the deprecated gnome-canvas. A
replacement was written but never finished.

2. the use of webkitgtk. For Gtk3 we need a newer version and this turns
out to be surprisingly challenging to build on Windows.

So to summarize, you're most welcome to join in in any way you see fit.
Small improvements can already be made in the existing GUI as far as I'm
concerned. User Experience (UX) is GUI toolkit independent IMO. If we
improve the UX now already, the same good UX can later be reimplemented
in a future toolkit. Finishing the port to gtk3 even though it will
likely be only a transition is still useful as well, considering the
time it will take to do all the rewrites.

Regards,

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Linux Luser
Thanks for the great responses! It does clarify quite a bit.


From the looks of things, it seems that the C -- C++ port would have the
most impact right now. It would take me awhile to get my C/C++ abilities
ramped up again. Where's the best place to start learning about gnucash
code? I don't know when I'd be able to start helping, but I'd at least want
to learn what I could.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 5, 2016, at 6:34 AM, Dave <[hidden email]> wrote:
>
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

I think the best leverage for an additional developer at this point would be to work on extracting the business logic from the GUI code. That work could be in C since it's mostly extract function refactors and the extracted functions have to be callable by the C GUI.

Part of that same job is to extract and combine the common code from Register and Register2; when Bob wrote it his vision was that the Reg2 stuff would work well enough that we could just drop Register, so he just copied the Register code and modified it. It didn't work out that way and it's become something of a maintenance headache because whenever we touch the guts of Register we have to remember to make the same changes in Register2. That hasn't always happened, so there are probably bugs that have been fixed in Register that still exist in Register2.

To start learning the code read through the Doxygen documentation at http://code.gnucash.org/docs/MASTER and browse the code at https://github.com/gnucash/gnucash.

For refreshing your C++ skills bear in mind that we're using C++11, templates, and shallow hierarchies (sometimes called "modern C++"). Have a look at http://wiki.gnucash.org/wiki/C%2B%2B, in particular http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.

Regards,
John Ralls



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Ted Creedon-2
As a retired Senior Project Manager responsible for maintaining many million lines of code I offer the following advice:

1. Stop and think.
2. Mark up the existing GUI's to indicate changes.
3. Write the New User's Manual and the System Adminstrator's Guide and Reference manual (tedious)
4.  Select an IDE and non make build system (CMake,Scons, etc.)
4. Write subroutine headers that compile and link
5. Complete coding (very boring)

If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.

Stay away from C++ unless you have significant decades of experience.

ROM effort for 1,000,000 lines of code / 100 lines per sub /per day = 10,000 subroutines /365= more time than we have..

=> We're prisoners of the existing code.

Ted Creedon, P.E.
________________________________________
From: gnucash-devel <gnucash-devel-bounces+tcreedon=[hidden email]> on behalf of John Ralls <[hidden email]>
Sent: Wednesday, October 5, 2016 12:12:59 AM
To: Dave
Cc: [hidden email]
Subject: Re: Are There Plans For A GUI Overhaul?

> On Oct 5, 2016, at 6:34 AM, Dave <[hidden email]> wrote:
>
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

I think the best leverage for an additional developer at this point would be to work on extracting the business logic from the GUI code. That work could be in C since it's mostly extract function refactors and the extracted functions have to be callable by the C GUI.

Part of that same job is to extract and combine the common code from Register and Register2; when Bob wrote it his vision was that the Reg2 stuff would work well enough that we could just drop Register, so he just copied the Register code and modified it. It didn't work out that way and it's become something of a maintenance headache because whenever we touch the guts of Register we have to remember to make the same changes in Register2. That hasn't always happened, so there are probably bugs that have been fixed in Register that still exist in Register2.

To start learning the code read through the Doxygen documentation at http://code.gnucash.org/docs/MASTER and browse the code at https://github.com/gnucash/gnucash.

For refreshing your C++ skills bear in mind that we're using C++11, templates, and shallow hierarchies (sometimes called "modern C++"). Have a look at http://wiki.gnucash.org/wiki/C%2B%2B, in particular http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.

Regards,
John Ralls



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Linux Luser
Thanks, Jon and Ted.

John, you inspired my optimism. Ted, you gave me a healthy dose of caution.
:)

So, I've done SysAdmin work for a living. In this field, lines of code are
thought of as liabilities. If I can get something done with 10 lines of
BASH code, I'll probably do it. Almost always, there needs to be a tangible
result to efforts within 1-2 weeks of starting. So I'm used to being ruled
more by economy and less by elegance. If I have an elegant solution, but it
will take time to write, I have to essentially work in secret, burning the
midnight oil. And even then, the idea may have actually been a bad one and
I just wasted all that time that I didn't get paid or praised for. :(

This is why I've by a Pythonista for some time. I use OOP when it makes
sense, and don't when it doesn't. I write a working solution today, and can
easily come back tomorrow to abstract this or that and make it maintainable
for my future self and others. So I've learned a little about evolving a
project, but only really in Python.

I've wanted to get back to C/C++ for some time. My main motivation was AVR
programming, which I've done a little bit of recently. However, none of my
background has been in larger application design and programming. It seems
that C++ has matured quite a bit since I touched it almost a decade ago.
When I learned it, I got as far as the STL, which seemed very advanced to
me at the time, but very interesting at the same time as I was finishing up
a mathematics degree and the STL seemed like a great way to create the sort
of abstractions that would help me begin writing programs to do
computational analysis. I probably would have gone that direction too, but
life took a turn for me and I got into managing Linux systems and hardware
and data centers.


Ted, I promise I'll give it some time. :)  I'm not in any particular rush.
I learn best by doing and it would be a pleasure if I could get up to speed
in C++ again and help out GnuCash at the same time. I really just need to
dive into C++ again. If I can't swim, then I can't swim and I'll have to
move on. From what I've read about it, though, things like "shallow
hierarchies" are practices I've already conceptually learned in the Python
world. When I learned Python, I began writing it like a Java programmer. I
have since been coaches completely away from that and classes are mostly
used for a type of namespacing, easier testing or the like. I've also found
that more and more, my programs are made up of generic computation over
data. So most of what's happening is that the application gets directed by
dictionaries that get processed to produce results. Basically, the Python
becomes more akin to a scheme program. I've found that this produces a
great amount of flexibility.


Thanks again for the pointers, warnings and generally good discussion. I
will look at the resources given. I've also found this
<https://github.com/rigtorp/awesome-modern-cpp>, which I'm hoping is also a
good place to start educating myself.

On Wed, Oct 5, 2016 at 5:09 AM, Ted Creedon <[hidden email]> wrote:

> As a retired Senior Project Manager responsible for maintaining many
> million lines of code I offer the following advice:
>
> 1. Stop and think.
> 2. Mark up the existing GUI's to indicate changes.
> 3. Write the New User's Manual and the System Adminstrator's Guide and
> Reference manual (tedious)
> 4.  Select an IDE and non make build system (CMake,Scons, etc.)
> 4. Write subroutine headers that compile and link
> 5. Complete coding (very boring)
>
> If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.
>
> Stay away from C++ unless you have significant decades of experience.
>
> ROM effort for 1,000,000 lines of code / 100 lines per sub /per day =
> 10,000 subroutines /365= more time than we have..
>
> => We're prisoners of the existing code.
>
> Ted Creedon, P.E.
> ________________________________________
> From: gnucash-devel <gnucash-devel-bounces+tcreedon=easystreet.net@
> gnucash.org> on behalf of John Ralls <[hidden email]>
> Sent: Wednesday, October 5, 2016 12:12:59 AM
> To: Dave
> Cc: [hidden email]
> Subject: Re: Are There Plans For A GUI Overhaul?
>
> > On Oct 5, 2016, at 6:34 AM, Dave <[hidden email]> wrote:
> >
> > Thanks for the great responses! It does clarify quite a bit.
> >
> >
> > From the looks of things, it seems that the C -- C++ port would have the
> > most impact right now. It would take me awhile to get my C/C++ abilities
> > ramped up again. Where's the best place to start learning about gnucash
> > code? I don't know when I'd be able to start helping, but I'd at least
> want
> > to learn what I could.
>
> I think the best leverage for an additional developer at this point would
> be to work on extracting the business logic from the GUI code. That work
> could be in C since it's mostly extract function refactors and the
> extracted functions have to be callable by the C GUI.
>
> Part of that same job is to extract and combine the common code from
> Register and Register2; when Bob wrote it his vision was that the Reg2
> stuff would work well enough that we could just drop Register, so he just
> copied the Register code and modified it. It didn't work out that way and
> it's become something of a maintenance headache because whenever we touch
> the guts of Register we have to remember to make the same changes in
> Register2. That hasn't always happened, so there are probably bugs that
> have been fixed in Register that still exist in Register2.
>
> To start learning the code read through the Doxygen documentation at
> http://code.gnucash.org/docs/MASTER and browse the code at
> https://github.com/gnucash/gnucash.
>
> For refreshing your C++ skills bear in mind that we're using C++11,
> templates, and shallow hierarchies (sometimes called "modern C++"). Have a
> look at http://wiki.gnucash.org/wiki/C%2B%2B, in particular
> http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.
>
> Regards,
> John Ralls
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



--
daV.e

"The reasonable man adapts himself to the conditions that surround him...
The unreasonable man adapts surrounding conditions to himself... All
progress depends on the unreasonable man." Bernard Shaw
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Ted Creedon-2

If you read and understand Scott Meyers books you're good to go.
________________________________________
From: [hidden email] <[hidden email]> on behalf of Dave <[hidden email]>
Sent: Wednesday, October 5, 2016 8:44 AM
To: Ted Creedon
Cc: John Ralls; [hidden email]
Subject: Re: Are There Plans For A GUI Overhaul?

Thanks, Jon and Ted.

John, you inspired my optimism. Ted, you gave me a healthy dose of caution. :)

So, I've done SysAdmin work for a living. In this field, lines of code are thought of as liabilities. If I can get something done with 10 lines of BASH code, I'll probably do it. Almost always, there needs to be a tangible result to efforts within 1-2 weeks of starting. So I'm used to being ruled more by economy and less by elegance. If I have an elegant solution, but it will take time to write, I have to essentially work in secret, burning the midnight oil. And even then, the idea may have actually been a bad one and I just wasted all that time that I didn't get paid or praised for. :(

This is why I've by a Pythonista for some time. I use OOP when it makes sense, and don't when it doesn't. I write a working solution today, and can easily come back tomorrow to abstract this or that and make it maintainable for my future self and others. So I've learned a little about evolving a project, but only really in Python.

I've wanted to get back to C/C++ for some time. My main motivation was AVR programming, which I've done a little bit of recently. However, none of my background has been in larger application design and programming. It seems that C++ has matured quite a bit since I touched it almost a decade ago. When I learned it, I got as far as the STL, which seemed very advanced to me at the time, but very interesting at the same time as I was finishing up a mathematics degree and the STL seemed like a great way to create the sort of abstractions that would help me begin writing programs to do computational analysis. I probably would have gone that direction too, but life took a turn for me and I got into managing Linux systems and hardware and data centers.


Ted, I promise I'll give it some time. :)  I'm not in any particular rush. I learn best by doing and it would be a pleasure if I could get up to speed in C++ again and help out GnuCash at the same time. I really just need to dive into C++ again. If I can't swim, then I can't swim and I'll have to move on. From what I've read about it, though, things like "shallow hierarchies" are practices I've already conceptually learned in the Python world. When I learned Python, I began writing it like a Java programmer. I have since been coaches completely away from that and classes are mostly used for a type of namespacing, easier testing or the like. I've also found that more and more, my programs are made up of generic computation over data. So most of what's happening is that the application gets directed by dictionaries that get processed to produce results. Basically, the Python becomes more akin to a scheme program. I've found that this produces a great amount of flexibility.


Thanks again for the pointers, warnings and generally good discussion. I will look at the resources given. I've also found this<https://github.com/rigtorp/awesome-modern-cpp>, which I'm hoping is also a good place to start educating myself.

On Wed, Oct 5, 2016 at 5:09 AM, Ted Creedon <[hidden email]<mailto:[hidden email]>> wrote:
As a retired Senior Project Manager responsible for maintaining many million lines of code I offer the following advice:

1. Stop and think.
2. Mark up the existing GUI's to indicate changes.
3. Write the New User's Manual and the System Adminstrator's Guide and Reference manual (tedious)
4.  Select an IDE and non make build system (CMake,Scons, etc.)
4. Write subroutine headers that compile and link
5. Complete coding (very boring)

If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.

Stay away from C++ unless you have significant decades of experience.

ROM effort for 1,000,000 lines of code / 100 lines per sub /per day = 10,000 subroutines /365= more time than we have..

=> We're prisoners of the existing code.

Ted Creedon, P.E.
________________________________________
From: gnucash-devel <gnucash-devel-bounces+tcreedon=[hidden email]<mailto:[hidden email]>> on behalf of John Ralls <[hidden email]<mailto:[hidden email]>>
Sent: Wednesday, October 5, 2016 12:12:59 AM
To: Dave
Cc: [hidden email]<mailto:[hidden email]>
Subject: Re: Are There Plans For A GUI Overhaul?

> On Oct 5, 2016, at 6:34 AM, Dave <[hidden email]<mailto:[hidden email]>> wrote:
>
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

I think the best leverage for an additional developer at this point would be to work on extracting the business logic from the GUI code. That work could be in C since it's mostly extract function refactors and the extracted functions have to be callable by the C GUI.

Part of that same job is to extract and combine the common code from Register and Register2; when Bob wrote it his vision was that the Reg2 stuff would work well enough that we could just drop Register, so he just copied the Register code and modified it. It didn't work out that way and it's become something of a maintenance headache because whenever we touch the guts of Register we have to remember to make the same changes in Register2. That hasn't always happened, so there are probably bugs that have been fixed in Register that still exist in Register2.

To start learning the code read through the Doxygen documentation at http://code.gnucash.org/docs/MASTER and browse the code at https://github.com/gnucash/gnucash.

For refreshing your C++ skills bear in mind that we're using C++11, templates, and shallow hierarchies (sometimes called "modern C++"). Have a look at http://wiki.gnucash.org/wiki/C%2B%2B, in particular http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.

Regards,
John Ralls



_______________________________________________
gnucash-devel mailing list
[hidden email]<mailto:[hidden email]>
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



--
daV.e

"The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man." Bernard Shaw

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2
In reply to this post by Linux Luser

> On Oct 5, 2016, at 5:44 PM, Dave <[hidden email]> wrote:
>
> Thanks, Jon and Ted.
>
> John, you inspired my optimism. Ted, you gave me a healthy dose of caution. :)
>
> So, I've done SysAdmin work for a living. In this field, lines of code are thought of as liabilities. If I can get something done with 10 lines of BASH code, I'll probably do it. Almost always, there needs to be a tangible result to efforts within 1-2 weeks of starting. So I'm used to being ruled more by economy and less by elegance. If I have an elegant solution, but it will take time to write, I have to essentially work in secret, burning the midnight oil. And even then, the idea may have actually been a bad one and I just wasted all that time that I didn't get paid or praised for. :(
>
> This is why I've by a Pythonista for some time. I use OOP when it makes sense, and don't when it doesn't. I write a working solution today, and can easily come back tomorrow to abstract this or that and make it maintainable for my future self and others. So I've learned a little about evolving a project, but only really in Python.

Dave,

I've also done sysadmin on and off for 30 years or so, and I do understand the need for quick-and-dirty in that environment.

Development is different. Elegant isn't necessarily required, but intelligible is. It's *really* important that what you write is clear and concise so that when it needs changing a  year or 10 down the road whoever ends up with the job (which might be you! never overestimate how much you'll remember about what you wrote 6 weeks ago, never mind 6 years ago) must be able to quickly understand what the code does so that it's not too hard to figure out the required mods. Code that clearly and concisely gets the job done while expressing the intent without requiring a lot of comments is the ultimate goal. The goal for a C++ core is the major release after next, expected around the end of 2020. By Ted's metric a full-time programmer (working only 5 days a week with 2 off rather than the 365 he wanted--typical project manager) would produce 800,000 lines of code and (if he's well disciplined and keeps his functions to between 20 and 50 lines each) 25,000 functions. Since C++ is a l!
 ot more expressive than C or Scheme, that's
pretty much a complete rewrite of GnuCash.

OTOH, Ted left off a crucial step: Write tests. Lots of tests. That takes time too, so our notional full-time programmer will rewrite only *half* of GnuCash in 4 years.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Christian Stimming-4
In reply to this post by Linux Luser
Dear Dave,

some additional voice on this topic: I'm the author who wrote the alternative
C++/Qt GUI program "cutecash" on top of the internal gnucash "engine" code.
That was in 2010. To my surprise, the code (with some minor fixes that I
committed today) still compiles, links, and runs. Just use cmake, set
WITH_CUTECASH=on (requires libglibmm-dev ), and make. One can open a gnucash
data file, browse through the accounts, edit a transaction and even undo the
edit (heh!). It will crash sooner or later due to various code changes in the
underlying object ownerships, but IMHO it might again be worth a look.

My take on the long term plans is that there are multiple plans around here.
Even a "migration to C++" can be done on various different levels, with
different strategies. For the cutecash experiment, I tested using the glibmm
wrappers, which map the glib stuff to C++ sufficiently well. If asked, I would
suggest to prefer glibmm usage over complete rewriting, and replacing glibmm-
wrapped objects by std c++ as a subsequent step. This would enable a switch to
C++ on the GUI side somewhat earlier than requiring a complete C++ rewrite
first. Then again, I probably won't be doing any of these work as I spend only
very little time on gnucash currently, and those decisions typically are done
by those people who actually invest their time in coding here. So don't take
my advice too seriously :-)

However, a new GUI layer will for sure have to start with a very small subset
of features. It might be a good path into more future-proof coding technology,
but it will for sure have only a small part of the current gnucash's features.
Maybe one can find a set of features with some small new additions that
attracts enough attention... but I don't know how this set of features would
have to look like.

If some people around here are looking into further GUI coding in C++,
preferrably using Qt toolkit, I would be interested to help out every now and
then. Feel free to contact me directly if interested.

Regards,

Christian






On Mittwoch, 5. Oktober 2016 08:44:44 CEST Dave wrote:

> Thanks, Jon and Ted.
>
> John, you inspired my optimism. Ted, you gave me a healthy dose of caution.
>
> :)
>
> So, I've done SysAdmin work for a living. In this field, lines of code are
> thought of as liabilities. If I can get something done with 10 lines of
> BASH code, I'll probably do it. Almost always, there needs to be a tangible
> result to efforts within 1-2 weeks of starting. So I'm used to being ruled
> more by economy and less by elegance. If I have an elegant solution, but it
> will take time to write, I have to essentially work in secret, burning the
> midnight oil. And even then, the idea may have actually been a bad one and
> I just wasted all that time that I didn't get paid or praised for. :(
>
> This is why I've by a Pythonista for some time. I use OOP when it makes
> sense, and don't when it doesn't. I write a working solution today, and can
> easily come back tomorrow to abstract this or that and make it maintainable
> for my future self and others. So I've learned a little about evolving a
> project, but only really in Python.
>
> I've wanted to get back to C/C++ for some time. My main motivation was AVR
> programming, which I've done a little bit of recently. However, none of my
> background has been in larger application design and programming. It seems
> that C++ has matured quite a bit since I touched it almost a decade ago.
> When I learned it, I got as far as the STL, which seemed very advanced to
> me at the time, but very interesting at the same time as I was finishing up
> a mathematics degree and the STL seemed like a great way to create the sort
> of abstractions that would help me begin writing programs to do
> computational analysis. I probably would have gone that direction too, but
> life took a turn for me and I got into managing Linux systems and hardware
> and data centers.
>
>
> Ted, I promise I'll give it some time. :)  I'm not in any particular rush.
> I learn best by doing and it would be a pleasure if I could get up to speed
> in C++ again and help out GnuCash at the same time. I really just need to
> dive into C++ again. If I can't swim, then I can't swim and I'll have to
> move on. From what I've read about it, though, things like "shallow
> hierarchies" are practices I've already conceptually learned in the Python
> world. When I learned Python, I began writing it like a Java programmer. I
> have since been coaches completely away from that and classes are mostly
> used for a type of namespacing, easier testing or the like. I've also found
> that more and more, my programs are made up of generic computation over
> data. So most of what's happening is that the application gets directed by
> dictionaries that get processed to produce results. Basically, the Python
> becomes more akin to a scheme program. I've found that this produces a
> great amount of flexibility.
>
>
> Thanks again for the pointers, warnings and generally good discussion. I
> will look at the resources given. I've also found this
> <https://github.com/rigtorp/awesome-modern-cpp>, which I'm hoping is also a
> good place to start educating myself.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Christian Stimming-4
In reply to this post by Linux Luser
On Dienstag, 4. Oktober 2016 21:34:51 CEST Dave wrote:
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

Some more pointers for learning about the internal C API: I wrote this wiki
page http://wiki.gnucash.org/wiki/C_API in 2011 as a Summe of Code student had
the same question. To me the explanation still seems valid. Maybe this is of
some help here.

Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Paul Phillips
Hi everyone,

 From the comments so far, it sounds like there is a huge mountain of
work here regardless of the route chosen to achieve it.  Not enough
active developers. And In past posts there was mention of a gnucash
bounty program that didn't succeed in attracting developers to the project.

Has any thought been given to approaching crowdfunding sites such as
bounty source or freedom sponsors to help speed development time?

Regards,

Paul.


On 06/10/16 07:24, Christian Stimming wrote:

> On Dienstag, 4. Oktober 2016 21:34:51 CEST Dave wrote:
>> Thanks for the great responses! It does clarify quite a bit.
>>
>>
>>  From the looks of things, it seems that the C -- C++ port would have the
>> most impact right now. It would take me awhile to get my C/C++ abilities
>> ramped up again. Where's the best place to start learning about gnucash
>> code? I don't know when I'd be able to start helping, but I'd at least want
>> to learn what I could.
> Some more pointers for learning about the internal C API: I wrote this wiki
> page http://wiki.gnucash.org/wiki/C_API in 2011 as a Summe of Code student had
> the same question. To me the explanation still seems valid. Maybe this is of
> some help here.
>
> Regards,
> Christian
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 13, 2016, at 2:59 AM, Paul Phillips <[hidden email]> wrote:
>
> Hi everyone,
>
> From the comments so far, it sounds like there is a huge mountain of work here regardless of the route chosen to achieve it.  Not enough active developers. And In past posts there was mention of a gnucash bounty program that didn't succeed in attracting developers to the project.
>
> Has any thought been given to approaching crowdfunding sites such as bounty source or freedom sponsors to help speed development time?

Paul,

Anything involving contract programmers would require someone to do the contracting and managing, which isn't something anyone in the development team has much interest in. So no, no thought has been given to raising money to hire programmers.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Paul Phillips
I'm interested in helping with the contracting and managing.


On 13/10/16 18:04, John Ralls wrote:

>> On Oct 13, 2016, at 2:59 AM, Paul Phillips <[hidden email]> wrote:
>>
>> Hi everyone,
>>
>>  From the comments so far, it sounds like there is a huge mountain of work here regardless of the route chosen to achieve it.  Not enough active developers. And In past posts there was mention of a gnucash bounty program that didn't succeed in attracting developers to the project.
>>
>> Has any thought been given to approaching crowdfunding sites such as bounty source or freedom sponsors to help speed development time?
> Paul,
>
> Anything involving contract programmers would require someone to do the contracting and managing, which isn't something anyone in the development team has much interest in. So no, no thought has been given to raising money to hire programmers.
>
> Regards,
> John Ralls
>


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 14, 2016, at 1:43 PM, Paul Phillips <[hidden email]> wrote:
>
> I'm interested in helping with the contracting and managing.
>
Paul,

No, I don't think so. Your commercial efforts with patchpitch present an enormous conflict of interest. Please go away.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Paul Phillips
Hi John,

It appears there's been a big misunderstanding.

I don't accept that there is a conflict of interest. Why do you think
there is? As you would be aware there are many examples of open source
projects that have successfully adopted a commercial model.

I'm offering to assist in accelerating development on the project in a
way that complements the project goals, and not just coding: e.g.
helping to create and maintain user documentation.

I'm happy to discuss further with you and/or others in the development
team.  Perhaps IRC or another medium would be best rather than the
mailing list.

If the consensus is not to accept my help, then I respect that, but it
would be unfortunate if this opportunity passed merely due to a
misunderstanding.

Regards,
Paul.


On 15/10/16 08:03, John Ralls wrote:

>> On Oct 14, 2016, at 1:43 PM, Paul Phillips <[hidden email]> wrote:
>>
>> I'm interested in helping with the contracting and managing.
>>
> Paul,
>
> No, I don't think so. Your commercial efforts with patchpitch present an enormous conflict of interest. Please go away.
>
> Regards,
> John Ralls
>


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 15, 2016, at 11:40 AM, Paul Phillips <[hidden email]> wrote:
>
> Hi John,
>
> It appears there's been a big misunderstanding.
>
> I don't accept that there is a conflict of interest. Why do you think there is? As you would be aware there are many examples of open source projects that have successfully adopted a commercial model.
>
> I'm offering to assist in accelerating development on the project in a way that complements the project goals, and not just coding: e.g. helping to create and maintain user documentation.
>
> I'm happy to discuss further with you and/or others in the development team.  Perhaps IRC or another medium would be best rather than the mailing list.
>
> If the consensus is not to accept my help, then I respect that, but it would be unfortunate if this opportunity passed merely due to a misunderstanding.

Paul,

I don't think there's any misunderstanding. Rather I think you're trying to sell the development team on something and being less than candid about your motivations.

The conflict is very simple: From your Linkedin profile:
    "I'm the founder, director and developer of PatchPitch.com. PatchPitch.com brings certainty, control and
     sustainability to Open Source Software, both for customers and developers, through a form of project managed micro
     crowd funding."
You also appear from Linkedin to have another company, SpikeSA, that is a project management consultancy.
The conflict should be obvious: You're offering to help with the contracting and managing on GnuCash's behalf of something that you're in business to provide. If you can't recognize that conflict then you're remarkably ethically challenged. The impression of ethical challenge is reinforced by the fact that you have approached us twice and both times failed to disclose your business interest.

But let's let that go for a moment. Let's also assume for a moment that we're interested in following up on the crowdfunding proposal and letting you run it. Apply for the job: Submit a CV and checkable references. I think the task involves the following:
1. Understanding the overall goals and priorities of the GnuCash development team for the next two release cycles (i.e., until 2020).
2. Analyzing those goals and priorities and developing concrete sub-projects to further them.
3. Writing requests-for-proposal for accomplishing those sub-projects.
4. Make credible estimates of the costs for contracting out those tasks and obtaining the requisite funds through crowdfunding, including whatever commissions/salary you'd require for performing this work.
4. Finding consulting software engineers and documenters with the ability to execute the sub-projects, get them to answer the RFPs, and select the best proposals.
5. Write contracts for the selected engineers and documenters to perform the work. Contracts need to include deliverables, concrete requirements for evaluating the acceptability of the deliverables, intermediate milestones for progress payments, and time frames for completion, plus all of the other legal stuff that goes into contracts like that.
6. Supervise the contractors to ensure that the milestones are met and administer payment.
7. Evaluate the provided code and documentation for good design, implementation, and correct language choice. Ensure that documentation and code is well-written, complies with GnuCash's coding standards, and is ready to merge into GnuCash at each milestone.

Your Linkedin profile suggests that your actual experience covers only items 1 (though not for GnuCash), 6, and maybe 7 (see below), and there's no real indication of actual proficiency there, it's just a bare CV.

Oh-by-the-way, since your employment at CSC seems to have been as a personal services contractor to BAE Systems I don't place a lot of credibility on the recommendations of your CSC colleagues. After all, they weren't the end recipients of the work you did.

The next question is how do we manage you? Are you proposing to do all of that work as a volunteer or do you expect to be paid? If the latter, what are your deliverables, intermediate milestones, and payment schedule? How do we evaluate your performance to those deliverables and milestones? How do we control your solicitation on crowdfunding sites, collection of the money, disbursement of the money, etc.?

You profess to "love open source", but what have you actually done for open source projects?

What about coding and code evaluation skills? Are there some significant features that you've implemented on major FLOSS projects that you can point to? Large pull requests or patch sets that you've reviewed? Mailing list discussions on a major project that you've contributed to in a meaningful way?

All of which falls far short of "adopting a commercial model", something that you haven't brought up before (raising more questions about your motivations). FWIW, Linas Vepstas, one of the original creators of GnuCash, tried that around 2000. You'll find vestiges in the copyrights on some of the older modules; look for "Linux Developers Group". It didn't work out. One or two developers have also tried selling GnuCash consulting and customization over the years, and that hasn't worked out very well either. It might be possible to build a business around GnuCash but past experience indicates it wouldn't be easy.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Paul Phillips
Hi John,

I'll begin with my motivation.

I've been using open source software for around 20 years.  I have been
using the Linux OS platform at home all that time and where possible
also at work. As anyone who's been a user of FOSS for a reasonable time
would know, it's not all plain sailing - many a time is required to
google forums and get under the hood to fiddle with a config file.

But there are many things that don't work, missing drivers, or that
missing a feature that would be really helpful. Apart from at work where
I've had to use a VM to run company-mandated windows software, or highly
specialised apps that don't have equivalents in the open source world,
I've gotten by.

Obviously one answer to the downsides is to roll up my sleeves to help
out.  The main trouble for me is that I'm relatively time poor.  I did
try to help out at one project called Gnome planner (and yes, you can
google it if you want).  I'm not proud of my early rookie use of git,
but I did write a patch to add a feature that I was missing from the
gantt chart planning tool.  It served me well while I was using it for
work (until they forced me to start using MS project). I submitted the
patch, but AFAIK it has never been applied to the main trunk.  I have
not chased this up.

PatchPitch is a reaction to the time poor thing, but still wanting to
help.  If I'm going to be of any use, I'll need to figure out a way of
deriving a partial income to compensate me for the time I spend,
otherwise I simply won't have time to help. So yes, this is a venture
designed to generate income for me and any future team that is built.

The main idea, like bountysource and one or two other sites is to crowd
fund features and bugs. And the idea behind this is to give users an
option to address specific areas of pain for them where previously they
may have had none. I am trying to improve where these other sites have
not been a raging success. They have seemed to focus on building the
site and hoping people will come. I was wanting to approach the project
team directly (hence my posts here) to work out whether we could figure
out a way that *could* work and hence have a greater chance of real success.

At this point, I'd like to say that I certainly agree with your conflict
of interest assessment if I was to become part of the development team
and I was soley responsible for outsourcing project management work from
donations - especially if there was a lack of transparency.

My original thinking, however, was that I would remain independent of
the Gnucash team.  I would help to raise funds and project manage the
work.  The funds would cover the costs of all the work, including my
own, which would all be disclosed. Initially, I expect that the actual
development work (software or other) would need to be outsourced. You
rightly point out that writing the proposals, selecting and supervising
the contractors, evaluating the quality of the code, design and
documentation are all important aspects of the process.  If I am not
part of the development team, then in order for the work to be
acceptable and therefore able to be merged into master, the team would
need to be involved somehow - either they would need to trust me or a
member of my team, or they would need to do some of that themselves.  
The main "interface" tasks that I see are the proposals, possibly the
selection of the workers, and the review and final acceptance of the
completed work.

And so the viability of this concept hinges on these interface tasks and
hence why I am discussing this now to gauge interest (especially in
light of the significant amount of code re-write ahead) and to see
whether there are possible ways to work cooperatively.

Thanks & regards,
Paul.

> Paul,
>
> I don't think there's any misunderstanding. Rather I think you're trying to sell the development team on something and being less than candid about your motivations.
>
> The conflict is very simple: From your Linkedin profile:
>      "I'm the founder, director and developer of PatchPitch.com. PatchPitch.com brings certainty, control and
>       sustainability to Open Source Software, both for customers and developers, through a form of project managed micro
>       crowd funding."
> You also appear from Linkedin to have another company, SpikeSA, that is a project management consultancy.
> The conflict should be obvious: You're offering to help with the contracting and managing on GnuCash's behalf of something that you're in business to provide. If you can't recognize that conflict then you're remarkably ethically challenged. The impression of ethical challenge is reinforced by the fact that you have approached us twice and both times failed to disclose your business interest.
>
> But let's let that go for a moment. Let's also assume for a moment that we're interested in following up on the crowdfunding proposal and letting you run it. Apply for the job: Submit a CV and checkable references. I think the task involves the following:
> 1. Understanding the overall goals and priorities of the GnuCash development team for the next two release cycles (i.e., until 2020).
> 2. Analyzing those goals and priorities and developing concrete sub-projects to further them.
> 3. Writing requests-for-proposal for accomplishing those sub-projects.
> 4. Make credible estimates of the costs for contracting out those tasks and obtaining the requisite funds through crowdfunding, including whatever commissions/salary you'd require for performing this work.
> 4. Finding consulting software engineers and documenters with the ability to execute the sub-projects, get them to answer the RFPs, and select the best proposals.
> 5. Write contracts for the selected engineers and documenters to perform the work. Contracts need to include deliverables, concrete requirements for evaluating the acceptability of the deliverables, intermediate milestones for progress payments, and time frames for completion, plus all of the other legal stuff that goes into contracts like that.
> 6. Supervise the contractors to ensure that the milestones are met and administer payment.
> 7. Evaluate the provided code and documentation for good design, implementation, and correct language choice. Ensure that documentation and code is well-written, complies with GnuCash's coding standards, and is ready to merge into GnuCash at each milestone.
>
> Your Linkedin profile suggests that your actual experience covers only items 1 (though not for GnuCash), 6, and maybe 7 (see below), and there's no real indication of actual proficiency there, it's just a bare CV.
>
> Oh-by-the-way, since your employment at CSC seems to have been as a personal services contractor to BAE Systems I don't place a lot of credibility on the recommendations of your CSC colleagues. After all, they weren't the end recipients of the work you did.
>
> The next question is how do we manage you? Are you proposing to do all of that work as a volunteer or do you expect to be paid? If the latter, what are your deliverables, intermediate milestones, and payment schedule? How do we evaluate your performance to those deliverables and milestones? How do we control your solicitation on crowdfunding sites, collection of the money, disbursement of the money, etc.?
>
> You profess to "love open source", but what have you actually done for open source projects?
>
> What about coding and code evaluation skills? Are there some significant features that you've implemented on major FLOSS projects that you can point to? Large pull requests or patch sets that you've reviewed? Mailing list discussions on a major project that you've contributed to in a meaningful way?
>
> All of which falls far short of "adopting a commercial model", something that you haven't brought up before (raising more questions about your motivations). FWIW, Linas Vepstas, one of the original creators of GnuCash, tried that around 2000. You'll find vestiges in the copyrights on some of the older modules; look for "Linux Developers Group". It didn't work out. One or two developers have also tried selling GnuCash consulting and customization over the years, and that hasn't worked out very well either. It might be possible to build a business around GnuCash but past experience indicates it wouldn't be easy.
>
> Regards,
> John Ralls
>


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

John Ralls-2

> On Oct 17, 2016, at 11:48 AM, Paul Phillips <[hidden email]> wrote:
>
> Hi John,
>
> I'll begin with my motivation.
>
> I've been using open source software for around 20 years.  I have been using the Linux OS platform at home all that time and where possible also at work. As anyone who's been a user of FOSS for a reasonable time would know, it's not all plain sailing - many a time is required to google forums and get under the hood to fiddle with a config file.
>
> But there are many things that don't work, missing drivers, or that missing a feature that would be really helpful. Apart from at work where I've had to use a VM to run company-mandated windows software, or highly specialised apps that don't have equivalents in the open source world, I've gotten by.
>
> Obviously one answer to the downsides is to roll up my sleeves to help out.  The main trouble for me is that I'm relatively time poor.  I did try to help out at one project called Gnome planner (and yes, you can google it if you want).  I'm not proud of my early rookie use of git, but I did write a patch to add a feature that I was missing from the gantt chart planning tool.  It served me well while I was using it for work (until they forced me to start using MS project). I submitted the patch, but AFAIK it has never been applied to the main trunk.  I have not chased this up.
>
> PatchPitch is a reaction to the time poor thing, but still wanting to help.  If I'm going to be of any use, I'll need to figure out a way of deriving a partial income to compensate me for the time I spend, otherwise I simply won't have time to help. So yes, this is a venture designed to generate income for me and any future team that is built.
>
> The main idea, like bountysource and one or two other sites is to crowd fund features and bugs. And the idea behind this is to give users an option to address specific areas of pain for them where previously they may have had none. I am trying to improve where these other sites have not been a raging success. They have seemed to focus on building the site and hoping people will come. I was wanting to approach the project team directly (hence my posts here) to work out whether we could figure out a way that *could* work and hence have a greater chance of real success.
>
> At this point, I'd like to say that I certainly agree with your conflict of interest assessment if I was to become part of the development team and I was soley responsible for outsourcing project management work from donations - especially if there was a lack of transparency.
>
> My original thinking, however, was that I would remain independent of the Gnucash team.  I would help to raise funds and project manage the work.  The funds would cover the costs of all the work, including my own, which would all be disclosed. Initially, I expect that the actual development work (software or other) would need to be outsourced. You rightly point out that writing the proposals, selecting and supervising the contractors, evaluating the quality of the code, design and documentation are all important aspects of the process.  If I am not part of the development team, then in order for the work to be acceptable and therefore able to be merged into master, the team would need to be involved somehow - either they would need to trust me or a member of my team, or they would need to do some of that themselves.  The main "interface" tasks that I see are the proposals, possibly the selection of the workers, and the review and final acceptance of the completed work.
>
> And so the viability of this concept hinges on these interface tasks and hence why I am discussing this now to gauge interest (especially in light of the significant amount of code re-write ahead) and to see whether there are possible ways to work cooperatively.

Paul,

Had you approached us that way originally you would have generated much less discord and suspicion. It's a shame you instead chose to start off the way you did.

I've explained more than once to you that no-one in the GnuCash team is interested in managing anyone. What you're proposing now is just another layer of the same thing: Sure, you'd contract with and project-manage the developers and documentors, but we'd still have to contract with you.

Incidentally, there's another wrinkle to this which makes it impossible for GnuCash to contract with anyone, but thinking of it reminds me of an entity that might be interested in working with you and helping you flesh out what you need to develop your business, maybe even to help you understand the prospective market for it.

The wrinkle is that there's no legal entity called GnuCash, so it's not possible for GnuCash to execute a contract with anyone. We have discussed a couple of times signing up with The Software Freedom Conservancy (https://sfconservancy.org/) to cover that angle but decided that at present we didn't have a need to. I suggest that you get in contact with them; they work internationally and have a good lawyer on their board (who used to be the counsel for the Gnome Foundation and so has a solid grasp of the legal needs of FOSS projects). I think you'll make more progress with your goals that way than with any individual project.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Are There Plans For A GUI Overhaul?

Paul Phillips
Hi John,

Indeed it is a shame, and I regret causing the discord and suspicion.  
Please accept my apologies.

Thanks for your insight and the link to the SFC.  I shall get in touch
with them.

The only other way of engaging with the GnuCash project without the need
of either a contract or management oversight is to create a fork.  It
would therefore obviously be completely optional whether the dev team
adopted any of the changes.  But if the fork development matched the
Gnucash roadmap and project guidelines, the chances of merger would
presumably increase.

However the key to enabling this to succeed is the user base, and as a
fork, the user base starts from scratch.

Regards,
Paul.

On 18/10/16 02:24, John Ralls wrote:

> Paul,
>
> Had you approached us that way originally you would have generated much less discord and suspicion. It's a shame you instead chose to start off the way you did.
>
> I've explained more than once to you that no-one in the GnuCash team is interested in managing anyone. What you're proposing now is just another layer of the same thing: Sure, you'd contract with and project-manage the developers and documentors, but we'd still have to contract with you.
>
> Incidentally, there's another wrinkle to this which makes it impossible for GnuCash to contract with anyone, but thinking of it reminds me of an entity that might be interested in working with you and helping you flesh out what you need to develop your business, maybe even to help you understand the prospective market for it.
>
> The wrinkle is that there's no legal entity called GnuCash, so it's not possible for GnuCash to execute a contract with anyone. We have discussed a couple of times signing up with The Software Freedom Conservancy (https://sfconservancy.org/) to cover that angle but decided that at present we didn't have a need to. I suggest that you get in contact with them; they work internationally and have a good lawyer on their board (who used to be the counsel for the Gnome Foundation and so has a solid grasp of the legal needs of FOSS projects). I think you'll make more progress with your goals that way than with any individual project.
>
> Regards,
> John Ralls
>


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12