Register2

[Derek Atkins]

Is removing them necessarily the best option?  Can they just be disabled
(perhaps integrated by a configure script)?

For example, I can imagine adding a --enable-register2 that would turn on
the new register code integration points via an #ifdef REGISTER2_ENABLED
in the code..  But the r2-specific files can be built always even if they
aren't integrated.  This would at least help make sure they don't bitrot,
and would allonw people to continue working and testing the code in the
interim.

-derek


On Mon, October 21, 2013 4:10 pm, Robert Fewell wrote:
> I have added a patch to bug 673193 to remove all new register2 files and
> amend existing files to restore the register back to the original setup. I
> will progress the register2 changes off line and try to resolve the
> existing open bugs.
>
> Regards,
>
>      Robert
>
>
> On 14 October 2013 18:52, Geert Janssens <janssens-geert at telenet.be>
> wrote:
>
>> **
>>
>> Hi Robert,
>>
>>
>>
>> Sorry to hear about your computer crash. I wish you good luck in
>> restoring
>> your working environment(s).
>>
>>
>>
>> Based on your feedback I propose to disable the register2 work for now
>> to
>> get 2.6 out of the door as planned in December. I seem to remember you
>> were
>> rather careful to keep the register2 code separate from the old code, so
>> disabling should be a relatively simple matter, right ?
>>
>>
>>
>> On which road is best for the new register, I can't really comment. I
>> have
>> no experience at all with cairo, nor with the current register's
>> internals.
>> So I can't estimate which path would be the easiest/fastest, and much
>> less
>> so which one would be the best in the long run.
>>
>>
>>
>> Geert
>>
>>
>>
>> On Sunday 13 October 2013 10:47:19 Robert Fewell wrote:
>>
>> > Guy's, I have had a bit of a disaster with my PC recently, I
>>
>> > accidentally deleted six VM hard disks by mistake which were on an
>>
>> > XFS file system partition. I have tried various programs to recover
>>
>> > them, each being 10G - 40G but to no avail and the backup I did have
>>
>> > was way out of date to be of use, must remember to do more regular
>>
>> > backups.
>>
>> >
>>
>> > As a result, I need to rebuild these VM's before I can continue with
>>
>> > the changes but two of them are more important to me than the one I
>>
>> > use to build GnuCash on so it will probably take a couple of weeks
>>
>> > before I get going again.
>>
>> >
>>
>> > Obviously I will need to remember / redo all the changes I had lined
>>
>> > up which included getting the scrollbar back to one, fixed the crash
>>
>> > on exit and some others I had sorted out partly.
>>
>> >
>>
>> > John's email beat mine, I do not wish to delay the release and would
>>
>> > be happy if the changes were pulled as I am not sure how long it
>>
>> > would be to get an acceptable register2 update.
>>
>> >
>>
>> > I would also like to ask if people think this register2 update is the
>>
>> > way to go, there is still a lot of work to be done but all the
>>
>> > elements are there OR scrap it and go down the rewrite what is there
>>
>> > with cairo calls replacing the canvas stuff. Not sure how much work
>>
>> > that would be, may be quicker or simpler ?
>>
>> >
>>
>> > Regards,
>>
>> >
>>
>> > Bob
>>
>> > _______________________________________________
>>
>> > gnucash-devel mailing list
>>
>> > gnucash-devel at gnucash.org
>>
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>>
>>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant