pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Deprecated g_atexit()


From: Detlef Graef
Subject: Re: [Pan-users] Deprecated g_atexit()
Date: Wed, 27 Apr 2016 18:30:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Hi,

Am 27.04.2016 um 11:01 schrieb Duncan:

> Detlef Graef posted on Tue, 26 Apr 2016 17:46:50 +0200 as excerpted:
> 
>> Hi Petr,
>>
>> Am 26.04.2016 um 17:33 schrieb Petr Kovar:
>>
>> [...]
>>
>>
>>>> Maybe someone may have a look at this patch too, if they are any
>>>> obvious problems?
>>>
>>> Would like to; do you have a working patch handy? If not, I could try
>>> to prepare one.
>>>
>>> This one won't merge as you say:
>>>
>>> https://git.gnome.org/browse/pan2/patch/?
> id=f7d917d4cbecab754b6cb6cb032fbd0705896e90
>>
>> It won't merge because body-pane.cc was modified till then.
>>
>> I can create a (git) patch, because I have manually applied the above
>> patch to the current source. I've tested Pan with the applied patch
>> without any problem till now.
>>
>> I will send you the patch, so you can test it.
> 
> Has anyone CCed or direct-mailed Heinrich asking about it?  (Petr, you're 
> in the best position to know if he's asked not to be contacted, or left a 
> forwarding address with you, or ...)  I hate to bother him if he's not on-
> list and replying any more, as seems to be the case, but seems to me if 
> he took the patch back out he's the best person to ask why.
> 
> For me, "leave it in for now" reads more like a backward compatibility 
> issue than an actual bug with the replacement code per se.  Maybe the 
> replacement code works well enough on current gtk2 or whatever library, 
> but not on the then-current minimum supported version of same.  In that 
> case, testing it on reasonably current setups isn't likely to help, but 
> it might for example fail to build on RHEL 5 (google says supported by RH 
> until Mar, 2017) or 6 (Nov, 2020) or some such, due to too old libraries 
> or code that doesn't work in old gcc.
> 
> In which case it'd be a policy question of whether we want to update the 
> minimum requirements and effectively drop support for building on those 
> old platforms without requiring dependency-hell updates.
> 
> Personally, I'm pretty forward leaning, not only running gentoo, but 
> running the ~arch (aka testing) keyword, and even installing live-git for 
> specific packages (like pan, where I've been live-git for ages) or even 
> entire subsystems (like kde4 some time ago, and now kde/frameworks/plasma/
> apps5), so while I understand concerns about supporting ancient versions 
> of whatever, I'm not the best person to ask about where to draw the line, 
> in practice.

I don't think this patch will brake anything on older OS or libraries.

This patch moves the cleanup work from the main() function to the
destructor/dtor of the class BodyPane where the corresponding allocation
of the resources are done. From the point of view of software design I
think this is more clean. The cleanup work is now done when the object
is deleted, that's the correct solution I think.

Maybe the patch can be improved, but using g_atexit() to do the cleanup
for an object is not the right way I think.

Maybe I am wrong, any other opinions?


Detlef




reply via email to

[Prev in Thread] Current Thread [Next in Thread]