OpenLP

Bug #1223644
Comment #15

Comment 15 for bug 1223644

Revision history for this message

Zachary Steele (zcsteele) wrote on 2013-09-23:

#15

Raoul -

First off, thanks for the work you've done to make the UNO interface function at all, given the state of that package. I can empathize with the rather unenviable position of needing to write writing code dependent on a poorly designed resource.

However, I see a couple of flaws in your argument for not attempting to add code to OpenLP for handling external-related errors.

First off, you make the statement "there is no GUI". OpenLP's GUI is based on Qt; the startup code imports the necessary Python dependencies during the startup process. If the Python interpreter was unable to load those resources it wouldn't even execute the call to create_engine() in the first place. The db.py file I have attached demonstrates this by displaying the Qt popup (without any secondary errors!) during the failure condition.

Secondly, you refuse to to make any attempt to cope with "everyone else's bad bugs". I'm not suggesting that you go around coding patches for every project that has any possible affect on OpenLP; what I am endorsing is "defensive programming" - much akin to the "defensive driving" taught in driving classes. As you can see with my attachment, the additional code is not at all complicated but allows OpenLP to report a meaningful error when LibreOffice (or any potential future replacement) fails.

You said "OpenLP development would be even slower". There is an element of truth to this, but how much time do you really lose by dropping my code in to the project? Also, as an open-source project there is not a hard cap on the number of active participants. I for one have no problem contributing to the codebase but if you really *want* OpenLP to be brittle I won't bother you with such issues in the future.

One point of consideration you may have missed is that of the end-user perspective. While any developer can trace the root cause of something like this back to its (external) source, all a user can see is "I clicked on the program, and then it crashed". The end-user is going to blame OpenLP because that was the program they were trying to run, not LibreOffice (which seems fine from an end-user perspective). I doubt most of the users are even /aware/ that the song database is tied to LibreOffice.

Raoul -

First off, thanks for the work you've done to make the UNO interface function at all, given the state of that package.  I can empathize with the rather unenviable position of needing to write writing code dependent on a poorly designed resource.

However, I see a couple of flaws in your argument for not attempting to add code to OpenLP for handling external-related errors.

First off, you make the statement "there is no GUI".  OpenLP's GUI is based on Qt; the startup code imports the necessary Python dependencies during the startup process.  If the Python interpreter was unable to load those resources it wouldn't even execute the call to create_engine() in the first place.  The db.py file I have attached demonstrates this by displaying the Qt popup (without any secondary errors!) during the failure condition.

Secondly, you refuse to to make any attempt to cope with "everyone else's bad bugs".  I'm not suggesting that you go around coding patches for every project that has any possible affect on OpenLP; what I am endorsing is "defensive programming" - much akin to the "defensive driving" taught in driving classes.  As you can see with my attachment, the additional code is not at all complicated but allows OpenLP to report a meaningful error when LibreOffice (or any potential future replacement) fails.

You said "OpenLP development would be even slower".  There is an element of truth to this, but how much time do you really lose by dropping my code in to the project?  Also, as an open-source project there is not a hard cap on the number of active participants.  I for one have no problem contributing to the codebase but if you really *want* OpenLP to be brittle I won't bother you with such issues in the future.

One point of consideration you may have missed is that of the end-user perspective.  While any developer can trace the root cause of something like this back to its (external) source,  all a user can see is "I clicked on the program, and then it crashed".  The end-user is going to blame OpenLP because that was the program they were trying to run, not LibreOffice (which seems fine from an end-user perspective).  I doubt most of the users are even /aware/ that the song database is tied to LibreOffice.