bibus-biblio-users — This is a general discussion list on Bibus software

Re: [Bibus-biblio-users] Bibus Future

[Jan B. <ja...@be...>]

Hello Pierre and everybody else,

there has been some activity again in the Ubuntu bug concerning the
incompatibility of bibus with libreoffice 4/python 3:
https://bugs.launchpad.net/ubuntu/+source/bibus/+bug/1070476

So I would like to ask again about whether anything is moving behind the
scenes or not...

Best regards,
Jan


Und es begab sich am 21.07.2013 01:19, dass Francisco Pina Martins schrieb:
> Hi Pierre,
> 
> 
> On 15/07/13 20:47, Pierre Martineau wrote:
>> Hi Francisco
>> 
>> Le 14/07/2013 16:59, Francisco Pina Martins a écrit :
>>> On 12/07/13 22:39, Pierre Martineau wrote:
>>>> Hello everybody and sorry for this long delay to reply.
>>> Hello Pierre,
>>> 
>>>> I stupidly forgot to change my email for the mailing list and
>>>> nothing arrived in my mailbox. It is now working but since I
>>>> cannot get old messages, I have to open a new thread.
>>>> 
>>>> I have to say that Francisco comments in 
>>>> http://sourceforge.net/mailarchive/message.php?msg_id=31126543 
>>>> are essentially correct. Bibus development has seriously stalled
>>>> in the last months (years ?). There are many reasons for that. I
>>>> put them in random order:
>>>> 
>>>> 1) Time, time and time. I'm very busy at work and tired when I
>>>> get home. 2) Bibus did essentially most of the features I
>>>> needed. 3) Alternative software like Zotero has matured and is
>>>> now a good and presumably better solution. 4) Recently,
>>>> libreoffice moved to python2.3 and there is no good and easy
>>>> solution to switch bibus to py2.3
>>> These are all very valid points. (except maybe that you mean
>>> python 3.2 and no 2.3 =-) )
>>>> Now solutions 1) I started a port to py2.3. The python part was
>>>> essentially easy and is presumably mostly done. There is a branch
>>>> called v2_0 for that and you can access it in the CVS. Don't rush
>>>> on it, it is still non-functional. The main window now opens with
>>>> only minimal errors in the console. I still have to debug many
>>>> things but it looks possible. At least it is presumably a
>>>> possible solution to get a libreoffice4 compatible release. It is
>>>> however not perfect since it uses phoenix-wxpython which is not
>>>> released and will not be finished soon. We will thus have to deal
>>>> with an alpha-quality library. LibO connection is still 
>>>> untested.
>>> This does scare *me* in particular. It may take years, before
>>> project phoenix ever gets a stable release.
>> You're right and it was my first thought. However, after testing it,
>> it seems more stable and mature than anticipated. We will however
>> have to deal with API changes, etc... And the end user will have to
>> use a non final version. You can be sure it won't be available in
>> Debian stable before years!
> Ok, so I guess we have two options then - phoenix and PyQt (more on
> gtk3 below).
>>>> 2) As suggested by Francisco, we could move to a new GUI. The
>>>> only stable and cross-platform python GUI is I think pyQt. We
>>>> will have however to rewrite everything.
>>> I *think* py-gtk3 can be used too. I have taken a quick look at
>>> it, when I started developing GUI apps, but compared to pyqt, it's
>>> memory footprint is larger, the documentation is horrible, and I am
>>> not sure the API is 100% stable (as some changes occur between GTK
>>> releases) - but I am just speculating here. I'm just saying there
>>> might be other options, despite preferring pyqt.
>> py-gtk is nice on linux but I'm not sure of the real status under 
>> Windows and MacOS. When I started bibus, it was for this reason that
>> I did not use it.
> You are right. Although GTK2 has a nice port and is quite stable under 
> windows and OS X, GTK3 is different. All that I could find were some 
> unofficial binaries...
>> 
>>> Also, I don't thing everything has to be rewritten - just the GUI 
>>> parts. Database connections, pyuno stuff, etc... should not need 
>>> relevant changes (other than porting to python3).
>> This is of course true but I have to say that the code is not the
>> best example of a clear split between GUI and non-GUI functions. I
>> started bibus to learn python and many parts should be re-write. 
>> There are also often some hacks to turn around bugs particularly for 
>> compatibility between linux and Windows.
> Let's make a clear cut in the new version. =-) As for platform
> compatibility, python3 has improved quite a lot on this aspect, and
> using a platform like Qt would surely solve the rest. (But I did not
> look at the code, so I could be wrong).
>>>> 3) Have a look at zotero and what kind of fusion we could do.
>>>> 
>>>> I think we must * try to have a working solution with phoenix.
>>>> This will help people that would like to continue to use bibus
>>>> and it is the easiest for the moment. The quality of phoenix is
>>>> not bad and I think a working solution is really possible. *
>>>> think about the future and start the transition.
>>> It is my opinion that if we really want to keep bibus going (at
>>> least mid term), a transition is the way to go.
>>>> I'm using more and more Zotero at work because of its
>>>> cross-platform and cross-software nature (OOo, libO, Word). One
>>>> of the main problem with bibus has been that it works both with
>>>> OOo and Word but that you cannot exchange documents between them.
>>>> Zotero solves this "nicely" or more exactly it is not possible I
>>>> think to make a better solution even if it is not perfect. I also
>>>> like the way Zotero collects doc on the Web and I seriously miss
>>>> this function in bibus. Finally Zotero works with footer and
>>>> end-of-doc bibliographies. I would be interested to know why you
>>>> still prefer bibus over Zotero and what bibus function is missing
>>>> in Zotero.
>>> I confess - I have never tried zotero. I was perfectly happy with 
>>> bibus until it stopped working with libreoffice 4. The only thing I
>>> was missing from bibus was "Rich text" support. This is supported
>>> natively in pyqt. As for the footer and end-of-doc bibliographies,
>>> Jonathan Schultz seems to have a somewhat working solution
>>> (although from what I understand it still needs some work to be
>>> more than "a hack").
>> What is "Rich text" support?
> Italics, Bold, different fonts, small caps, that sort of thing.
>>> What I particularly like about bibus is the multiple database
>>> backends (although I have only used mysql a few times, the times I
>>> did, it was a real life-saver), the fact that it does not add any
>>> toolbars to libreoffice (I like to keep the chrome of LO as clean
>>> as possible, to see as much of the document as I can fit in my
>>> screen) to work and insert citations, the consistent interface, the
>>> API for pubmed search and the easy to use and modify "import
>>> filters". This means that I can work with bibus and libreoffice
>>> without any other programs open (except the PDFs I am accessing) -
>>> it might not seem like much, since today's computers can handle a
>>> lot. But not having the browser open to work on a document makes
>>> world of difference on my netbook, for instance.
>> There is now a stand-alone version of Zotero. I never tried it since
>> I have always a Firefox running but it is supposed to work well. They
>> choose to add a toolbar in OOo, but it should be very easy to remove
>> it and add shortcuts if you prefer. Concerning multiple backends, it
>> is presumably possible to implement this in Zotero. I'm sure they
>> would be happy if somebody proposes to do it.
> If in the end we decide that further developing bibus is not worth it
> it's something I will definitely look into.
>>> That being said, do you honestly think that a "rewrite" of bibus
>>> is worth it? Or do not think it might bring anything good?
>>> 
>>> Personally, I think it is worth whatever time I can spare into it. 
>>> It's good quality software, with a good community around it.
>> My current feeling is that porting to a new GUI will be a huge and 
>> unnecessary effort. We should port to python3/phoenix and think to 
>> future plans. I see 2 options: * We think Zotero is ok and we join
>> the effort by adding what we thing are the missing features. * We
>> think a new software is required and we start from scratch. Many 
>> functions are easy to implement if the design is right at the
>> beginning. Most of my effort in bibus has been to understand pyuno
>> when it was an experimental and buggy module, and trying to keep
>> compatibility between old bibus versions and new ones. Even in that
>> case, keeping some compatibility with Zotero could be nice. I started
>> to work on this some years ago. There is a bibus branch called
>> "plugin" that actually used zotero plugin for its interaction with
>> OOo. My idea was to convert step by step bibus to a Zotero compatible
>> state by first adding support for plugin, then styles, then finally
>> the database format. This way you could collect references on the web
>> with Zotero and use either Zotero or bibus to insert and format your
>> paper. If we do it right it could eventually end up as a libO
>> extension and eventually as the official LibO bibliographic software
>> and replace the crappy libO bibliographic module (ok, this is maybe a
>> bit too optimistic).
> Ok, so I guess it all "boils down" to this. First of all, I am willing
> to help you with the porting to phoenix. I have to learn that toolkit,
> so it might take a while before I do something useful, tough (but I
> *will* get there). Here is my opinion on the future plans: One of the
> things I enjoy about FOSS is *choice*. I can choose my desktop 
> environment, my browser, and even the scheduler in my kernel. And I
> like to be able to say - "I choose A, not because B suck, but because I
> like A better. They are both good solutions.". This means that if my
> needs change for some reason, I have other attractive options. 
> Improving on zotero, might even work in the mid-term, but long term,
> *I know* I will regret not having more choice. That being said - like
> every good and well thought out projects, a common ground is
> important. Maybe, as a future plan, we can focus on a total rewrite,
> but based around the "standards" that zotero has created. The idea you
> laid out in * number 2, is really appalling to me. This would leave me
> (everybody else) with a *choice* - this time around, based on the same
> standard, which would mean, a simple way to switch between the chosen
> bibliography manager.
> 
> Anyone else care to chime in?
> 
>> Thank you for your interest in bibus! Pierre
> You're welcome. Thank you for creating it.
> 
> Francisco


-- 
Jan Beyer				happy Debian Maintainer	;-)	

mail	ja...@be...			GPG key ID 0x0CA6B4AA
jabber	bea...@ja...
web	http://www.beathovn.de/

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Jan B. <ja...@be...>]

I just uploaded bibus 1.5.2-3 to Debian unstable incorporating this patch.
So it will migrate to testing in (hopefully) ten days or so.

Best regards,
Jan

Und es begab sich am 07.09.2013 13:59, dass Pierre Martineau schrieb:
> Please try the update BibOOoBase.py file at
> 
> https://sourceforge.net/p/bibus-biblio/patches/33/
> 
> Pierre


-- 
Jan Beyer				happy Debian Maintainer	;-)	

mail	ja...@be...			GPG key ID 0x0CA6B4AA
jabber	bea...@ja...
web	http://www.beathovn.de/

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Nikolaos L. <nl...@hc...>]

Hi Pierre,

Great!

I am a happy bibus user again.

Many thanks!

Keep up the excellent work.

Nikos

On 09/07/2013 02:59 PM, Pierre Martineau wrote:
> Please try the update BibOOoBase.py file at
>
> https://sourceforge.net/p/bibus-biblio/patches/33/
>
> Pierre
>
>
> Le 07/09/2013 13:47, Pierre Martineau a écrit :
>> Don't update except if you want to break it!
>> The problem is exactly the one I described since the change occurred
>> between 4.0 and 4.1.1
>>
>> I have made a fix. I will post it to the list. Please test and report.
>>
>> Pierre
>>
>>
>> Le 07/09/2013 13:05, Nikolaos Lampadariou a écrit :
>>> Hi Pierre,
>>>
>>> Thank you very much for you reply.
>>>
>>> Here is the output from those commands you asked:
>>>
>>> ---------------------------------------------------------------
>>> nikos@ocean-068:~$ python2.7
>>> Python 2.7.5+ (default, Jun  2 2013, 13:26:34)
>>> [GCC 4.7.3] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import uno
>>>>>> import pyuno
>>>>>>
>>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in<module>
>>> __main__.RuntimeException: pyuno.getConstantByName:
>>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>>>>
>>> -----------------------------------------------------------------------
>>>
>>> I have another debian testing box with an older installation for which I
>>> haven't done any dist-upgrade for more than two months and on which
>>> bibus works just fine. Looking up with dpkg the problematic new box
>>> seems to run libreoffice 1:4.1.0-5 while to older one 1:4.0.3-3. Your
>>> python commands in the older box return the following: "0L"
>>>
>>> Should I try to upgrade the libreoffice in the old box to see if it
>>> brakes also?
>>>
>>> Thanks
>>>
>>> Nikos
>>>
>>>
>>> On 09/07/2013 01:33 PM, Pierre Martineau wrote:
>>>> Hi everybody,
>>>>
>>>> this looks like a change in the last LibreOffice 1.1.1
>>>>
>>>> I suppose Debian testing use 1.1.1
>>>> I looked in the release notes and there is indeed a modification of the
>>>> function pyuno.getConstantByName
>>>>
>>>> Here is the libOOo note
>>>> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Python
>>>>
>>>>    Python
>>>>
>>>>       Due to changes for the new type.rdb format, uno.getConstantByName no
>>>> longer works for UNOIDL enum members, only for UNOIDL constants. Even
>>>> though uno.getConstantByName had only been documented to work for
>>>> constants, existing code might have relied on the fact that it somewhat
>>>> accidentally also worked for enum members. See also fdo#66031
>>>>
>>>> As you can see in bibus error we are using
>>>>
>>>> pyuno.getConstantByName( constant )
>>>>
>>>> and pyuno returns the error
>>>>
>>>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant
>>>>
>>>> pyun and the last LibOOo is right,
>>>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant but an
>>>> enum.
>>>>
>>>> I have now to find how to get the same for an enum!
>>>>
>>>> Just to be sure could you please test by typing
>>>>> python27
>>>>>> import uno
>>>>>> import pyuno
>>>>>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>>>>
>>>>
>>>> You should then get the same error.
>>>> In my case (LibOOo 3.5.7) it works like a charm.
>>>>
>>>>
>>>> Pierre
>>>>
>>>>
>>>> Le 05/09/2013 11:18, Nikolaos Lampadariou a écrit :
>>>>> I/ve done a fresh install of bibus along with a fresh install of debian
>>>>> testing and bibus does not run.
>>>>>
>>>>> When started from a terminal I get the following error:
>>>>>
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> Traceback (most recent call last):
>>>>>      File "/usr/bin/bibus", line 232, in<module>
>>>>>        bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
>>>>>      File "/usr/share/bibus/BibFrame.py", line 31, in __init__
>>>>>        self.__loadConnectionModule()
>>>>>      File "/usr/share/bibus/BibFrame.py", line 1432, in
>>>>> __loadConnectionModule
>>>>>        import OOo
>>>>>      File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>>> _uno_import
>>>>>        return _g_delegatee( name, *optargs, **kwargs )
>>>>>      File "/usr/share/bibus/OOo.py", line 54, in<module>
>>>>>        from bibOOo.bibOOoPlus import *
>>>>>      File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>>> _uno_import
>>>>>        return _g_delegatee( name, *optargs, **kwargs )
>>>>>      File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in<module>
>>>>>        from bibOOo.bibOOoBase import *
>>>>>      File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>>> _uno_import
>>>>>        return _g_delegatee( name, *optargs, **kwargs )
>>>>>      File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in<module>
>>>>>        DIRECT_VALUE =
>>>>> uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>>>      File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in
>>>>> getConstantByName
>>>>>        return pyuno.getConstantByName( constant )
>>>>> uno.RuntimeException: pyuno.getConstantByName:
>>>>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> My system has libreoffice 4.1.0-5 and it seems to have both python
>>>>> 2.7.5-4 and python3 3.3.2-15.
>>>>>
>>>>> I've read through the following post
>>>>> http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a
>>>>> similar problem but my bibframe.py file does not seem to contain exactly
>>>>> these lines mentioned in the 3rd post.
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> Nikos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>>> Discover the easy way to master current and previous Microsoft
>>>> technologies
>>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>>>>
>>>> _______________________________________________
>>>> Bibus-biblio-users mailing list
>>>> Bib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bibus-biblio-users mailing list
>> Bib...@li...
>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Pierre M. <p.m...@la...>]

Please try the update BibOOoBase.py file at

https://sourceforge.net/p/bibus-biblio/patches/33/

Pierre


Le 07/09/2013 13:47, Pierre Martineau a écrit :
> Don't update except if you want to break it!
> The problem is exactly the one I described since the change occurred
> between 4.0 and 4.1.1
> 
> I have made a fix. I will post it to the list. Please test and report.
> 
> Pierre
> 
> 
> Le 07/09/2013 13:05, Nikolaos Lampadariou a écrit :
>> Hi Pierre,
>>
>> Thank you very much for you reply.
>>
>> Here is the output from those commands you asked:
>>
>> ---------------------------------------------------------------
>> nikos@ocean-068:~$ python2.7
>> Python 2.7.5+ (default, Jun  2 2013, 13:26:34)
>> [GCC 4.7.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import uno
>>>>> import pyuno
>>>>>
>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> __main__.RuntimeException: pyuno.getConstantByName:
>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>>>
>> -----------------------------------------------------------------------
>>
>> I have another debian testing box with an older installation for which I
>> haven't done any dist-upgrade for more than two months and on which
>> bibus works just fine. Looking up with dpkg the problematic new box
>> seems to run libreoffice 1:4.1.0-5 while to older one 1:4.0.3-3. Your
>> python commands in the older box return the following: "0L"
>>
>> Should I try to upgrade the libreoffice in the old box to see if it
>> brakes also?
>>
>> Thanks
>>
>> Nikos
>>
>>
>> On 09/07/2013 01:33 PM, Pierre Martineau wrote:
>>> Hi everybody,
>>>
>>> this looks like a change in the last LibreOffice 1.1.1
>>>
>>> I suppose Debian testing use 1.1.1
>>> I looked in the release notes and there is indeed a modification of the
>>> function pyuno.getConstantByName
>>>
>>> Here is the libOOo note
>>> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Python
>>>
>>>   Python
>>>
>>>      Due to changes for the new type.rdb format, uno.getConstantByName no
>>> longer works for UNOIDL enum members, only for UNOIDL constants. Even
>>> though uno.getConstantByName had only been documented to work for
>>> constants, existing code might have relied on the fact that it somewhat
>>> accidentally also worked for enum members. See also fdo#66031
>>>
>>> As you can see in bibus error we are using
>>>
>>> pyuno.getConstantByName( constant )
>>>
>>> and pyuno returns the error
>>>
>>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant
>>>
>>> pyun and the last LibOOo is right,
>>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant but an
>>> enum.
>>>
>>> I have now to find how to get the same for an enum!
>>>
>>> Just to be sure could you please test by typing
>>>> python27
>>>>> import uno
>>>>> import pyuno
>>>>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>>>
>>>
>>> You should then get the same error.
>>> In my case (LibOOo 3.5.7) it works like a charm.
>>>
>>>
>>> Pierre
>>>
>>>
>>> Le 05/09/2013 11:18, Nikolaos Lampadariou a écrit :
>>>> I/ve done a fresh install of bibus along with a fresh install of debian
>>>> testing and bibus does not run.
>>>>
>>>> When started from a terminal I get the following error:
>>>>
>>>> -------------------------------------------------------------------
>>>>
>>>> Traceback (most recent call last):
>>>>     File "/usr/bin/bibus", line 232, in<module>
>>>>       bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
>>>>     File "/usr/share/bibus/BibFrame.py", line 31, in __init__
>>>>       self.__loadConnectionModule()
>>>>     File "/usr/share/bibus/BibFrame.py", line 1432, in
>>>> __loadConnectionModule
>>>>       import OOo
>>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>> _uno_import
>>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>>     File "/usr/share/bibus/OOo.py", line 54, in<module>
>>>>       from bibOOo.bibOOoPlus import *
>>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>> _uno_import
>>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>>     File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in<module>
>>>>       from bibOOo.bibOOoBase import *
>>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>>> _uno_import
>>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>>     File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in<module>
>>>>       DIRECT_VALUE =
>>>> uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in
>>>> getConstantByName
>>>>       return pyuno.getConstantByName( constant )
>>>> uno.RuntimeException: pyuno.getConstantByName:
>>>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> My system has libreoffice 4.1.0-5 and it seems to have both python
>>>> 2.7.5-4 and python3 3.3.2-15.
>>>>
>>>> I've read through the following post
>>>> http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a
>>>> similar problem but my bibframe.py file does not seem to contain exactly
>>>> these lines mentioned in the 3rd post.
>>>>
>>>> Any suggestions?
>>>>
>>>> Thanks in advance
>>>>
>>>> Nikos
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>> Discover the easy way to master current and previous Microsoft
>>> technologies
>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>>>
>>> _______________________________________________
>>> Bibus-biblio-users mailing list
>>> Bib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>>>
>>
> 
> 
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
> 

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Pierre M. <p.m...@la...>]

Don't update except if you want to break it!
The problem is exactly the one I described since the change occurred
between 4.0 and 4.1.1

I have made a fix. I will post it to the list. Please test and report.

Pierre


Le 07/09/2013 13:05, Nikolaos Lampadariou a écrit :
> Hi Pierre,
> 
> Thank you very much for you reply.
> 
> Here is the output from those commands you asked:
> 
> ---------------------------------------------------------------
> nikos@ocean-068:~$ python2.7
> Python 2.7.5+ (default, Jun  2 2013, 13:26:34)
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import uno
>>>> import pyuno
>>>>
> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> __main__.RuntimeException: pyuno.getConstantByName:
> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>>
> -----------------------------------------------------------------------
> 
> I have another debian testing box with an older installation for which I
> haven't done any dist-upgrade for more than two months and on which
> bibus works just fine. Looking up with dpkg the problematic new box
> seems to run libreoffice 1:4.1.0-5 while to older one 1:4.0.3-3. Your
> python commands in the older box return the following: "0L"
> 
> Should I try to upgrade the libreoffice in the old box to see if it
> brakes also?
> 
> Thanks
> 
> Nikos
> 
> 
> On 09/07/2013 01:33 PM, Pierre Martineau wrote:
>> Hi everybody,
>>
>> this looks like a change in the last LibreOffice 1.1.1
>>
>> I suppose Debian testing use 1.1.1
>> I looked in the release notes and there is indeed a modification of the
>> function pyuno.getConstantByName
>>
>> Here is the libOOo note
>> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Python
>>
>>   Python
>>
>>      Due to changes for the new type.rdb format, uno.getConstantByName no
>> longer works for UNOIDL enum members, only for UNOIDL constants. Even
>> though uno.getConstantByName had only been documented to work for
>> constants, existing code might have relied on the fact that it somewhat
>> accidentally also worked for enum members. See also fdo#66031
>>
>> As you can see in bibus error we are using
>>
>> pyuno.getConstantByName( constant )
>>
>> and pyuno returns the error
>>
>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant
>>
>> pyun and the last LibOOo is right,
>> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant but an
>> enum.
>>
>> I have now to find how to get the same for an enum!
>>
>> Just to be sure could you please test by typing
>>> python27
>>>> import uno
>>>> import pyuno
>>>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>>
>>
>> You should then get the same error.
>> In my case (LibOOo 3.5.7) it works like a charm.
>>
>>
>> Pierre
>>
>>
>> Le 05/09/2013 11:18, Nikolaos Lampadariou a écrit :
>>> I/ve done a fresh install of bibus along with a fresh install of debian
>>> testing and bibus does not run.
>>>
>>> When started from a terminal I get the following error:
>>>
>>> -------------------------------------------------------------------
>>>
>>> Traceback (most recent call last):
>>>     File "/usr/bin/bibus", line 232, in<module>
>>>       bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
>>>     File "/usr/share/bibus/BibFrame.py", line 31, in __init__
>>>       self.__loadConnectionModule()
>>>     File "/usr/share/bibus/BibFrame.py", line 1432, in
>>> __loadConnectionModule
>>>       import OOo
>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>> _uno_import
>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>     File "/usr/share/bibus/OOo.py", line 54, in<module>
>>>       from bibOOo.bibOOoPlus import *
>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>> _uno_import
>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>     File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in<module>
>>>       from bibOOo.bibOOoBase import *
>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in
>>> _uno_import
>>>       return _g_delegatee( name, *optargs, **kwargs )
>>>     File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in<module>
>>>       DIRECT_VALUE =
>>> uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in
>>> getConstantByName
>>>       return pyuno.getConstantByName( constant )
>>> uno.RuntimeException: pyuno.getConstantByName:
>>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>>
>>> ------------------------------------------------------------------------
>>>
>>> My system has libreoffice 4.1.0-5 and it seems to have both python
>>> 2.7.5-4 and python3 3.3.2-15.
>>>
>>> I've read through the following post
>>> http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a
>>> similar problem but my bibframe.py file does not seem to contain exactly
>>> these lines mentioned in the 3rd post.
>>>
>>> Any suggestions?
>>>
>>> Thanks in advance
>>>
>>> Nikos
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft
>> technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bibus-biblio-users mailing list
>> Bib...@li...
>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>>
> 

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Nikolaos L. <nl...@hc...>]

Hi Pierre,

Thank you very much for you reply.

Here is the output from those commands you asked:

---------------------------------------------------------------
nikos@ocean-068:~$ python2.7
Python 2.7.5+ (default, Jun  2 2013, 13:26:34)
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import uno
 >>> import pyuno
 >>> 
pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
__main__.RuntimeException: pyuno.getConstantByName: 
com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
 >>>
-----------------------------------------------------------------------

I have another debian testing box with an older installation for which I 
haven't done any dist-upgrade for more than two months and on which 
bibus works just fine. Looking up with dpkg the problematic new box 
seems to run libreoffice 1:4.1.0-5 while to older one 1:4.0.3-3. Your 
python commands in the older box return the following: "0L"

Should I try to upgrade the libreoffice in the old box to see if it 
brakes also?

Thanks

Nikos


On 09/07/2013 01:33 PM, Pierre Martineau wrote:
> Hi everybody,
>
> this looks like a change in the last LibreOffice 1.1.1
>
> I suppose Debian testing use 1.1.1
> I looked in the release notes and there is indeed a modification of the
> function pyuno.getConstantByName
>
> Here is the libOOo note
> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Python
>
>   Python
>
>      Due to changes for the new type.rdb format, uno.getConstantByName no
> longer works for UNOIDL enum members, only for UNOIDL constants. Even
> though uno.getConstantByName had only been documented to work for
> constants, existing code might have relied on the fact that it somewhat
> accidentally also worked for enum members. See also fdo#66031
>
> As you can see in bibus error we are using
>
> pyuno.getConstantByName( constant )
>
> and pyuno returns the error
>
> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant
>
> pyun and the last LibOOo is right,
> com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant but an enum.
>
> I have now to find how to get the same for an enum!
>
> Just to be sure could you please test by typing
>> python27
>>> import uno
>>> import pyuno
>>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>
> You should then get the same error.
> In my case (LibOOo 3.5.7) it works like a charm.
>
>
> Pierre
>
>
> Le 05/09/2013 11:18, Nikolaos Lampadariou a écrit :
>> I/ve done a fresh install of bibus along with a fresh install of debian
>> testing and bibus does not run.
>>
>> When started from a terminal I get the following error:
>>
>> -------------------------------------------------------------------
>>
>> Traceback (most recent call last):
>>     File "/usr/bin/bibus", line 232, in<module>
>>       bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
>>     File "/usr/share/bibus/BibFrame.py", line 31, in __init__
>>       self.__loadConnectionModule()
>>     File "/usr/share/bibus/BibFrame.py", line 1432, in __loadConnectionModule
>>       import OOo
>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>>       return _g_delegatee( name, *optargs, **kwargs )
>>     File "/usr/share/bibus/OOo.py", line 54, in<module>
>>       from bibOOo.bibOOoPlus import *
>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>>       return _g_delegatee( name, *optargs, **kwargs )
>>     File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in<module>
>>       from bibOOo.bibOOoBase import *
>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>>       return _g_delegatee( name, *optargs, **kwargs )
>>     File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in<module>
>>       DIRECT_VALUE =
>> uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>>     File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in
>> getConstantByName
>>       return pyuno.getConstantByName( constant )
>> uno.RuntimeException: pyuno.getConstantByName:
>> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
>>
>> ------------------------------------------------------------------------
>>
>> My system has libreoffice 4.1.0-5 and it seems to have both python
>> 2.7.5-4 and python3 3.3.2-15.
>>
>> I've read through the following post
>> http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a
>> similar problem but my bibframe.py file does not seem to contain exactly
>> these lines mentioned in the 3rd post.
>>
>> Any suggestions?
>>
>> Thanks in advance
>>
>> Nikos
>>
>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[Pierre M. <p.m...@la...>]

Hi everybody,

this looks like a change in the last LibreOffice 1.1.1

I suppose Debian testing use 1.1.1
I looked in the release notes and there is indeed a modification of the
function pyuno.getConstantByName

Here is the libOOo note
https://wiki.documentfoundation.org/ReleaseNotes/4.1#Python

 Python

    Due to changes for the new type.rdb format, uno.getConstantByName no
longer works for UNOIDL enum members, only for UNOIDL constants. Even
though uno.getConstantByName had only been documented to work for
constants, existing code might have relied on the fact that it somewhat
accidentally also worked for enum members. See also fdo#66031

As you can see in bibus error we are using

pyuno.getConstantByName( constant )

and pyuno returns the error

com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant

pyun and the last LibOOo is right,
com.sun.star.beans.PropertyState.DIRECT_VALUE is not a constant but an enum.

I have now to find how to get the same for an enum!

Just to be sure could you please test by typing
> python27
>> import uno
>> import pyuno
>> pyuno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")

You should then get the same error.
In my case (LibOOo 3.5.7) it works like a charm.


Pierre


Le 05/09/2013 11:18, Nikolaos Lampadariou a écrit :
> I/ve done a fresh install of bibus along with a fresh install of debian 
> testing and bibus does not run.
> 
> When started from a terminal I get the following error:
> 
> -------------------------------------------------------------------
> 
> Traceback (most recent call last):
>    File "/usr/bin/bibus", line 232, in <module>
>      bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
>    File "/usr/share/bibus/BibFrame.py", line 31, in __init__
>      self.__loadConnectionModule()
>    File "/usr/share/bibus/BibFrame.py", line 1432, in __loadConnectionModule
>      import OOo
>    File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>      return _g_delegatee( name, *optargs, **kwargs )
>    File "/usr/share/bibus/OOo.py", line 54, in <module>
>      from bibOOo.bibOOoPlus import *
>    File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>      return _g_delegatee( name, *optargs, **kwargs )
>    File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in <module>
>      from bibOOo.bibOOoBase import *
>    File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
>      return _g_delegatee( name, *optargs, **kwargs )
>    File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in <module>
>      DIRECT_VALUE = 
> uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
>    File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in 
> getConstantByName
>      return pyuno.getConstantByName( constant )
> uno.RuntimeException: pyuno.getConstantByName: 
> com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant
> 
> ------------------------------------------------------------------------
> 
> My system has libreoffice 4.1.0-5 and it seems to have both python 
> 2.7.5-4 and python3 3.3.2-15.
> 
> I've read through the following post 
> http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a 
> similar problem but my bibframe.py file does not seem to contain exactly 
> these lines mentioned in the 3rd post.
> 
> Any suggestions?
> 
> Thanks in advance
> 
> Nikos
> 
> 
> 
> 
> 

Re: [Bibus-biblio-users] Bibus does not run in debian testing

[<ja...@be...>]

I can confirm the issue and add the information, that python-uno package is installed (i.e. the python 2.7 compatible version) and not python3-uno.

Pierre, do you have any pointers/patches?

Best regards,
Jan

[Bibus-biblio-users] Bibus does not run in debian testing

[Nikolaos L. <nl...@hc...>]

I/ve done a fresh install of bibus along with a fresh install of debian 
testing and bibus does not run.

When started from a terminal I get the following error:

-------------------------------------------------------------------

Traceback (most recent call last):
   File "/usr/bin/bibus", line 232, in <module>
     bibframe1 = BibFrame.BibFrame(None, -1, BIB.TITLE, name=APPNAME)
   File "/usr/share/bibus/BibFrame.py", line 31, in __init__
     self.__loadConnectionModule()
   File "/usr/share/bibus/BibFrame.py", line 1432, in __loadConnectionModule
     import OOo
   File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
     return _g_delegatee( name, *optargs, **kwargs )
   File "/usr/share/bibus/OOo.py", line 54, in <module>
     from bibOOo.bibOOoPlus import *
   File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
     return _g_delegatee( name, *optargs, **kwargs )
   File "/usr/share/bibus/bibOOo/bibOOoPlus.py", line 22, in <module>
     from bibOOo.bibOOoBase import *
   File "/usr/lib/python2.7/dist-packages/uno.py", line 268, in _uno_import
     return _g_delegatee( name, *optargs, **kwargs )
   File "/usr/share/bibus/bibOOo/bibOOoBase.py", line 45, in <module>
     DIRECT_VALUE = 
uno.getConstantByName("com.sun.star.beans.PropertyState.DIRECT_VALUE")
   File "/usr/lib/python2.7/dist-packages/uno.py", line 51, in 
getConstantByName
     return pyuno.getConstantByName( constant )
uno.RuntimeException: pyuno.getConstantByName: 
com.sun.star.beans.PropertyState.DIRECT_VALUEis not a constant

------------------------------------------------------------------------

My system has libreoffice 4.1.0-5 and it seems to have both python 
2.7.5-4 and python3 3.3.2-15.

I've read through the following post 
http://sourceforge.net/p/bibus-biblio/bugs/151/ which seems to report a 
similar problem but my bibframe.py file does not seem to contain exactly 
these lines mentioned in the 3rd post.

Any suggestions?

Thanks in advance

Nikos





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Bibus-biblio-users] Bibus Future

[Francisco P. M. <f.p...@gm...>]

Hi Pierre,


On 15/07/13 20:47, Pierre Martineau wrote:
> Hi Francisco
>
> Le 14/07/2013 16:59, Francisco Pina Martins a écrit :
>> On 12/07/13 22:39, Pierre Martineau wrote:
>>> Hello everybody and sorry for this long delay to reply.
>> Hello Pierre,
>>
>>> I stupidly forgot to change my email for the mailing list and nothing
>>> arrived in my mailbox. It is now working but since I cannot get old
>>> messages, I have to open a new thread.
>>>
>>> I have to say that Francisco comments in
>>> http://sourceforge.net/mailarchive/message.php?msg_id=31126543
>>> are essentially correct. Bibus development has seriously stalled in
>>> the last months (years ?). There are many reasons for that. I put them
>>> in random order:
>>>
>>> 1) Time, time and time. I'm very busy at work and tired when I get home.
>>> 2) Bibus did essentially most of the features I needed.
>>> 3) Alternative software like Zotero has matured and is now a good and
>>> presumably better solution.
>>> 4) Recently, libreoffice moved to python2.3 and there is no good and
>>> easy solution to switch bibus to py2.3
>> These are all very valid points. (except maybe that you mean python
>> 3.2 and no 2.3 =-) )
>>> Now solutions
>>> 1) I started a port to py2.3. The python part was essentially easy and
>>> is presumably mostly done. There is a branch called v2_0 for that and
>>> you can access it in the CVS. Don't rush on it, it is still
>>> non-functional.
>>> The main window now opens with only minimal errors in the console. I
>>> still have to debug many things but it looks possible. At least it is
>>> presumably a possible solution to get a libreoffice4 compatible
>>> release. It is however not perfect since it uses phoenix-wxpython
>>> which is not released and will not be finished soon. We will thus have
>>> to deal with an alpha-quality library. LibO connection is still
>>> untested.
>> This does scare*me*  in particular. It may take years, before project
>> phoenix ever gets a stable release.
> You're right and it was my first thought. However, after testing it, it
> seems more stable and mature than anticipated. We will however have to
> deal with API changes, etc... And the end user will have to use a non
> final version. You can be sure it won't be available in Debian stable
> before years!
Ok, so I guess we have two options then - phoenix and PyQt (more on gtk3 
below).
>>> 2) As suggested by Francisco, we could move to a new GUI. The only
>>> stable and cross-platform python GUI is I think pyQt. We will have
>>> however to rewrite everything.
>> I*think*  py-gtk3 can be used too. I have taken a quick look at it,
>> when I started developing GUI apps, but compared to pyqt, it's memory
>> footprint is larger, the documentation is horrible, and I am not sure
>> the API is 100% stable (as some changes occur between GTK releases) -
>> but I am just speculating here. I'm just saying there might be other
>> options, despite preferring pyqt.
> py-gtk is nice on linux but I'm not sure of the real status under
> Windows and MacOS.
> When I started bibus, it was for this reason that I did not use it.
You are right. Although GTK2 has a nice port and is quite stable under 
windows and OS X, GTK3 is different. All that I could find were some 
unofficial binaries...
>
>> Also, I don't thing everything has to be rewritten - just the GUI
>> parts. Database connections, pyuno stuff, etc... should not need
>> relevant changes (other than porting to python3).
> This is of course true but I have to say that the code is not the best
> example of a clear split between GUI and non-GUI functions.
> I started bibus to learn python and many parts should be re-write.
> There are also often some hacks to turn around bugs particularly for
> compatibility between linux and Windows.
Let's make a clear cut in the new version. =-)
As for platform compatibility, python3 has improved quite a lot on this 
aspect, and using a platform like Qt would surely solve the rest. (But I 
did not look at the code, so I could be wrong).
>>> 3) Have a look at zotero and what kind of fusion we could do.
>>>
>>> I think we must
>>> * try to have a working solution with phoenix. This will help people
>>> that would like to continue to use bibus and it is the easiest for the
>>> moment. The quality of phoenix is not bad and I think a working
>>> solution is really possible.
>>> * think about the future and start the transition.
>> It is my opinion that if we really want to keep bibus going (at least
>> mid term), a transition is the way to go.
>>> I'm using more and more Zotero at work because of its cross-platform
>>> and cross-software nature (OOo, libO, Word). One of the main problem
>>> with bibus has been that it works both with OOo and Word but that you
>>> cannot exchange documents between them. Zotero solves this "nicely" or
>>> more exactly it is not possible I think to make a better solution even
>>> if it is not perfect. I also like the way Zotero collects doc on the
>>> Web and I seriously miss this function in bibus. Finally Zotero works
>>> with footer and end-of-doc bibliographies.
>>> I would be interested to know why you still prefer bibus over Zotero
>>> and what bibus function is missing in Zotero.
>> I confess - I have never tried zotero. I was perfectly happy with
>> bibus until it stopped working with libreoffice 4.
>> The only thing I was missing from bibus was "Rich text" support. This
>> is supported natively in pyqt.
>> As for the footer and end-of-doc bibliographies, Jonathan Schultz
>> seems to have a somewhat working solution (although from what I
>> understand it still needs some work to be more than "a hack").
> What is "Rich text" support?
Italics, Bold, different fonts, small caps, that sort of thing.
>> What I particularly like about bibus is the multiple database backends
>> (although I have only used mysql a few times, the times I did, it was
>> a real life-saver), the fact that it does not add any toolbars to
>> libreoffice (I like to keep the chrome of LO as clean as possible, to
>> see as much of the document as I can fit in my screen) to work and
>> insert citations, the consistent interface, the API for pubmed search
>> and the easy to use and modify "import filters".
>> This means that I can work with bibus and libreoffice without any
>> other programs open (except the PDFs I am accessing) - it might not
>> seem like much, since today's computers can handle a lot. But not
>> having the browser open to work on a document makes world of
>> difference on my netbook, for instance.
> There is now a stand-alone version of Zotero. I never tried it since I
> have always a Firefox running but it is supposed to work well.
> They choose to add a toolbar in OOo, but it should be very easy to
> remove it and add shortcuts if you prefer.
> Concerning multiple backends, it is presumably possible to implement
> this in Zotero. I'm sure they would be happy if somebody proposes to do it.
If in the end we decide that further developing bibus is not worth it 
it's something I will definitely look into.
>> That being said, do you honestly think that a "rewrite" of bibus is
>> worth it? Or do not think it might bring anything good?
>>
>> Personally, I think it is worth whatever time I can spare into it.
>> It's good quality software, with a good community around it.
> My current feeling is that porting to a new GUI will be a huge and
> unnecessary effort. We should port to python3/phoenix and think to
> future plans. I see 2 options:
> * We think Zotero is ok and we join the effort by adding what we thing
> are the missing features.
> * We think a new software is required and we start from scratch. Many
> functions are easy to implement if the design is right at the beginning.
> Most of my effort in bibus has been to understand pyuno when it was an
> experimental and buggy module, and trying to keep compatibility between
> old bibus versions and new ones. Even in that case, keeping some
> compatibility with Zotero could be nice. I started to work on this some
> years ago. There is a bibus branch called "plugin" that actually used
> zotero plugin for its interaction with OOo. My idea was to convert step
> by step bibus to a Zotero compatible state by first adding support for
> plugin, then styles, then finally the database format. This way you
> could collect references on the web with Zotero and use either Zotero or
> bibus to insert and format your paper. If we do it right it could
> eventually end up as a libO extension and eventually as the official
> LibO bibliographic software and replace the crappy libO bibliographic
> module (ok, this is maybe a bit too optimistic).
Ok, so I guess it all "boils down" to this.
First of all, I am willing to help you with the porting to phoenix. I 
have to learn that toolkit, so it might take a while before I do 
something useful, tough (but I *will* get there).
Here is my opinion on the future plans:
One of the things I enjoy about FOSS is *choice*. I can choose my 
desktop environment, my browser, and even the scheduler in my kernel. 
And I like to be able to say - "I choose A, not because B suck, but 
because I like A better. They are both good solutions.". This means that 
if my needs change for some reason, I have other attractive options.
Improving on zotero, might even work in the mid-term, but long term, *I 
know* I will regret not having more choice.
That being said - like every good and well thought out projects, a 
common ground is important.
Maybe, as a future plan, we can focus on a total rewrite, but based 
around the "standards" that zotero has created. The idea you laid out in 
* number 2, is really appalling to me.
This would leave me (everybody else) with a *choice* - this time around, 
based on the same standard, which would mean, a simple way to switch 
between the chosen bibliography manager.

Anyone else care to chime in?

> Thank you for your interest in bibus!
> Pierre
You're welcome. Thank you for creating it.

Francisco
>>> Sorry again for my long silence
>>> Pierre
>>>
>> Thank you for your reply! It is very much appreciated!
>>
>> Francisco
>>
>>> ------------------------------------------------------------------------------
>>>
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>
>>> _______________________________________________
>>> Bibus-biblio-users mailing list
>>> Bib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users

Re: [Bibus-biblio-users] Bibus Future

[Pierre M. <p.m...@la...>]

Hi Francisco

Le 14/07/2013 16:59, Francisco Pina Martins a écrit :

> On 12/07/13 22:39, Pierre Martineau wrote:
>> Hello everybody and sorry for this long delay to reply.
> Hello Pierre,
>
>> I stupidly forgot to change my email for the mailing list and nothing
>> arrived in my mailbox. It is now working but since I cannot get old
>> messages, I have to open a new thread.
>>
>> I have to say that Francisco comments in
>> http://sourceforge.net/mailarchive/message.php?msg_id=31126543
>> are essentially correct. Bibus development has seriously stalled in
>> the last months (years ?). There are many reasons for that. I put them
>> in random order:
>>
>> 1) Time, time and time. I'm very busy at work and tired when I get home.
>> 2) Bibus did essentially most of the features I needed.
>> 3) Alternative software like Zotero has matured and is now a good and
>> presumably better solution.
>> 4) Recently, libreoffice moved to python2.3 and there is no good and
>> easy solution to switch bibus to py2.3
> These are all very valid points. (except maybe that you mean python
> 3.2 and no 2.3 =-) )
>> Now solutions
>> 1) I started a port to py2.3. The python part was essentially easy and
>> is presumably mostly done. There is a branch called v2_0 for that and
>> you can access it in the CVS. Don't rush on it, it is still
>> non-functional.
>> The main window now opens with only minimal errors in the console. I
>> still have to debug many things but it looks possible. At least it is
>> presumably a possible solution to get a libreoffice4 compatible
>> release. It is however not perfect since it uses phoenix-wxpython
>> which is not released and will not be finished soon. We will thus have
>> to deal with an alpha-quality library. LibO connection is still
>> untested.
> This does scare *me* in particular. It may take years, before project
> phoenix ever gets a stable release.

You're right and it was my first thought. However, after testing it, it
seems more stable and mature than anticipated. We will however have to
deal with API changes, etc... And the end user will have to use a non
final version. You can be sure it won't be available in Debian stable
before years!

>> 2) As suggested by Francisco, we could move to a new GUI. The only
>> stable and cross-platform python GUI is I think pyQt. We will have
>> however to rewrite everything.
> I *think* py-gtk3 can be used too. I have taken a quick look at it,
> when I started developing GUI apps, but compared to pyqt, it's memory
> footprint is larger, the documentation is horrible, and I am not sure
> the API is 100% stable (as some changes occur between GTK releases) -
> but I am just speculating here. I'm just saying there might be other
> options, despite preferring pyqt.

py-gtk is nice on linux but I'm not sure of the real status under
Windows and MacOS.
When I started bibus, it was for this reason that I did not use it.

> Also, I don't thing everything has to be rewritten - just the GUI
> parts. Database connections, pyuno stuff, etc... should not need
> relevant changes (other than porting to python3).

This is of course true but I have to say that the code is not the best
example of a clear split between GUI and non-GUI functions.
I started bibus to learn python and many parts should be re-write.
There are also often some hacks to turn around bugs particularly for
compatibility between linux and Windows.

>> 3) Have a look at zotero and what kind of fusion we could do.
>>
>> I think we must
>> * try to have a working solution with phoenix. This will help people
>> that would like to continue to use bibus and it is the easiest for the
>> moment. The quality of phoenix is not bad and I think a working
>> solution is really possible.
>> * think about the future and start the transition.
> It is my opinion that if we really want to keep bibus going (at least
> mid term), a transition is the way to go.
>> I'm using more and more Zotero at work because of its cross-platform
>> and cross-software nature (OOo, libO, Word). One of the main problem
>> with bibus has been that it works both with OOo and Word but that you
>> cannot exchange documents between them. Zotero solves this "nicely" or
>> more exactly it is not possible I think to make a better solution even
>> if it is not perfect. I also like the way Zotero collects doc on the
>> Web and I seriously miss this function in bibus. Finally Zotero works
>> with footer and end-of-doc bibliographies.
>> I would be interested to know why you still prefer bibus over Zotero
>> and what bibus function is missing in Zotero.
> I confess - I have never tried zotero. I was perfectly happy with
> bibus until it stopped working with libreoffice 4.
> The only thing I was missing from bibus was "Rich text" support. This
> is supported natively in pyqt.
> As for the footer and end-of-doc bibliographies, Jonathan Schultz
> seems to have a somewhat working solution (although from what I
> understand it still needs some work to be more than "a hack").

What is "Rich text" support?

> What I particularly like about bibus is the multiple database backends
> (although I have only used mysql a few times, the times I did, it was
> a real life-saver), the fact that it does not add any toolbars to
> libreoffice (I like to keep the chrome of LO as clean as possible, to
> see as much of the document as I can fit in my screen) to work and
> insert citations, the consistent interface, the API for pubmed search
> and the easy to use and modify "import filters".
> This means that I can work with bibus and libreoffice without any
> other programs open (except the PDFs I am accessing) - it might not
> seem like much, since today's computers can handle a lot. But not
> having the browser open to work on a document makes world of
> difference on my netbook, for instance.

There is now a stand-alone version of Zotero. I never tried it since I
have always a Firefox running but it is supposed to work well.
They choose to add a toolbar in OOo, but it should be very easy to
remove it and add shortcuts if you prefer.
Concerning multiple backends, it is presumably possible to implement
this in Zotero. I'm sure they would be happy if somebody proposes to do it.

> That being said, do you honestly think that a "rewrite" of bibus is
> worth it? Or do not think it might bring anything good?
>
> Personally, I think it is worth whatever time I can spare into it.
> It's good quality software, with a good community around it.

My current feeling is that porting to a new GUI will be a huge and
unnecessary effort. We should port to python3/phoenix and think to
future plans. I see 2 options:
* We think Zotero is ok and we join the effort by adding what we thing
are the missing features.
* We think a new software is required and we start from scratch. Many
functions are easy to implement if the design is right at the beginning.
Most of my effort in bibus has been to understand pyuno when it was an
experimental and buggy module, and trying to keep compatibility between
old bibus versions and new ones. Even in that case, keeping some
compatibility with Zotero could be nice. I started to work on this some
years ago. There is a bibus branch called "plugin" that actually used
zotero plugin for its interaction with OOo. My idea was to convert step
by step bibus to a Zotero compatible state by first adding support for
plugin, then styles, then finally the database format. This way you
could collect references on the web with Zotero and use either Zotero or
bibus to insert and format your paper. If we do it right it could
eventually end up as a libO extension and eventually as the official
LibO bibliographic software and replace the crappy libO bibliographic
module (ok, this is maybe a bit too optimistic).

Thank you for your interest in bibus!
Pierre

>> Sorry again for my long silence
>> Pierre
>>
> Thank you for your reply! It is very much appreciated!
>
> Francisco
>
>> ------------------------------------------------------------------------------
>>
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bibus-biblio-users mailing list
>> Bib...@li...
>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users

Re: [Bibus-biblio-users] Bibus Future

[Francisco P. M. <f.p...@gm...>]

On 12/07/13 22:39, Pierre Martineau wrote:
> Hello everybody and sorry for this long delay to reply.
Hello Pierre,

> I stupidly forgot to change my email for the mailing list and nothing
> arrived in my mailbox. It is now working but since I cannot get old
> messages, I have to open a new thread.
>
> I have to say that Francisco comments in
> http://sourceforge.net/mailarchive/message.php?msg_id=31126543
> are essentially correct. Bibus development has seriously stalled in
> the last months (years ?). There are many reasons for that. I put them
> in random order:
>
> 1) Time, time and time. I'm very busy at work and tired when I get home.
> 2) Bibus did essentially most of the features I needed.
> 3) Alternative software like Zotero has matured and is now a good and
> presumably better solution.
> 4) Recently, libreoffice moved to python2.3 and there is no good and
> easy solution to switch bibus to py2.3
These are all very valid points. (except maybe that you mean python 3.2 
and no 2.3 =-) )
> Now solutions
> 1) I started a port to py2.3. The python part was essentially easy and
> is presumably mostly done. There is a branch called v2_0 for that and
> you can access it in the CVS. Don't rush on it, it is still
> non-functional.
> The main window now opens with only minimal errors in the console. I
> still have to debug many things but it looks possible. At least it is
> presumably a possible solution to get a libreoffice4 compatible
> release. It is however not perfect since it uses phoenix-wxpython
> which is not released and will not be finished soon. We will thus have
> to deal with an alpha-quality library. LibO connection is still untested.
This does scare *me* in particular. It may take years, before project 
phoenix ever gets a stable release.
> 2) As suggested by Francisco, we could move to a new GUI. The only
> stable and cross-platform python GUI is I think pyQt. We will have
> however to rewrite everything.
I *think* py-gtk3 can be used too. I have taken a quick look at it, when 
I started developing GUI apps, but compared to pyqt, it's memory 
footprint is larger, the documentation is horrible, and I am not sure 
the API is 100% stable (as some changes occur between GTK releases) - 
but I am just speculating here. I'm just saying there might be other 
options, despite preferring pyqt.
Also, I don't thing everything has to be rewritten - just the GUI parts. 
Database connections, pyuno stuff, etc... should not need relevant 
changes (other than porting to python3).
> 3) Have a look at zotero and what kind of fusion we could do.
>
> I think we must
> * try to have a working solution with phoenix. This will help people
> that would like to continue to use bibus and it is the easiest for the
> moment. The quality of phoenix is not bad and I think a working
> solution is really possible.
> * think about the future and start the transition.
It is my opinion that if we really want to keep bibus going (at least 
mid term), a transition is the way to go.
> I'm using more and more Zotero at work because of its cross-platform
> and cross-software nature (OOo, libO, Word). One of the main problem
> with bibus has been that it works both with OOo and Word but that you
> cannot exchange documents between them. Zotero solves this "nicely" or
> more exactly it is not possible I think to make a better solution even
> if it is not perfect. I also like the way Zotero collects doc on the
> Web and I seriously miss this function in bibus. Finally Zotero works
> with footer and end-of-doc bibliographies.
> I would be interested to know why you still prefer bibus over Zotero
> and what bibus function is missing in Zotero.
I confess - I have never tried zotero. I was perfectly happy with bibus 
until it stopped working with libreoffice 4.
The only thing I was missing from bibus was "Rich text" support. This is 
supported natively in pyqt.
As for the footer and end-of-doc bibliographies, Jonathan Schultz seems 
to have a somewhat working solution (although from what I understand it 
still needs some work to be more than "a hack").

What I particularly like about bibus is the multiple database backends 
(although I have only used mysql a few times, the times I did, it was a 
real life-saver), the fact that it does not add any toolbars to 
libreoffice (I like to keep the chrome of LO as clean as possible, to 
see as much of the document as I can fit in my screen) to work and 
insert citations, the consistent interface, the API for pubmed search 
and the easy to use and modify "import filters".
This means that I can work with bibus and libreoffice without any other 
programs open (except the PDFs I am accessing) - it might not seem like 
much, since today's computers can handle a lot. But not having the 
browser open to work on a document makes world of difference on my 
netbook, for instance.

That being said, do you honestly think that a "rewrite" of bibus is 
worth it? Or do not think it might bring anything good?

Personally, I think it is worth whatever time I can spare into it. It's 
good quality software, with a good community around it.
> Sorry again for my long silence
> Pierre
>
Thank you for your reply! It is very much appreciated!

Francisco

> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users

[Bibus-biblio-users] Bibus Future

[Pierre M. <p.m...@la...>]

Hello everybody and sorry for this long delay to reply.

I stupidly forgot to change my email for the mailing list and nothing
arrived in my mailbox. It is now working but since I cannot get old
messages, I have to open a new thread.

I have to say that Francisco comments in
http://sourceforge.net/mailarchive/message.php?msg_id=31126543
are essentially correct. Bibus development has seriously stalled in
the last months (years ?). There are many reasons for that. I put them
in random order:

1) Time, time and time. I'm very busy at work and tired when I get home.
2) Bibus did essentially most of the features I needed.
3) Alternative software like Zotero has matured and is now a good and
presumably better solution.
4) Recently, libreoffice moved to python2.3 and there is no good and
easy solution to switch bibus to py2.3

Now solutions
1) I started a port to py2.3. The python part was essentially easy and
is presumably mostly done. There is a branch called v2_0 for that and
you can access it in the CVS. Don't rush on it, it is still
non-functional.
The main window now opens with only minimal errors in the console. I
still have to debug many things but it looks possible. At least it is
presumably a possible solution to get a libreoffice4 compatible
release. It is however not perfect since it uses phoenix-wxpython
which is not released and will not be finished soon. We will thus have
to deal with an alpha-quality library. LibO connection is still untested.

2) As suggested by Francisco, we could move to a new GUI. The only
stable and cross-platform python GUI is I think pyQt. We will have
however to rewrite everything.

3) Have a look at zotero and what kind of fusion we could do.

I think we must
* try to have a working solution with phoenix. This will help people
that would like to continue to use bibus and it is the easiest for the
moment. The quality of phoenix is not bad and I think a working
solution is really possible.
* think about the future and start the transition.

I'm using more and more Zotero at work because of its cross-platform
and cross-software nature (OOo, libO, Word). One of the main problem
with bibus has been that it works both with OOo and Word but that you
cannot exchange documents between them. Zotero solves this "nicely" or
more exactly it is not possible I think to make a better solution even
if it is not perfect. I also like the way Zotero collects doc on the
Web and I seriously miss this function in bibus. Finally Zotero works
with footer and end-of-doc bibliographies.
I would be interested to know why you still prefer bibus over Zotero
and what bibus function is missing in Zotero.

Sorry again for my long silence
Pierre

Re: [Bibus-biblio-users] The Future of Bibus

[Francisco P. M. <f.p...@gm...>]

First of all, thank you Jan for contacting Pierre!

This is good news, as I too would prefer not to fork bibus.

Regardless, I still think that bibus needs some attention (and I am 
willing to back that up with code contributions).

I will eagerly wait for Pierre's opinion on this, as he is the author// 
of bibus and obviously the better suited person to decide on some sort 
of a roadmap.

Cheers,

Francisco

On 12/07/13 10:29, Jan Beyer wrote:
> Hello,
>
> I contacted Pierre privately and it turned out that some email trouble
> prevented him from receiving the mails in this thread. I hope, this is
> sorted out now and this mail will reach him, so he will be able to reply
> correctly in the thread.
>
> As bibus maintainer in Debian, I would strongly prefer not forking bibus, if
> this is possible. I fear, that this would result in confusion and turn out
> bad for everybody.
> But Pierre will probably tell us some more details on the status of bibus
> himself...
>
> Best regards,
> Jan
>
> Und es begab sich am 04.07.2013 10:56, dass Francisco Pina Martins schrieb:
>> Thank you Jonathan, for the feedback,
>>
>> This is exactly what I mean. Not just a port of Bibus to a newer
>> framework, but also improve on it's shortcomings and add new features if
>> required.
>>
>> At this point I think we should start thinking about a 'roadmap' of some
>> sort.
>> We should also pick a new toolkit to draw the GUI and start gathering
>> more people to this effort, because honestly I don't think 2 people in
>> part time can pull this off in a reasonable amount of time.
>>
>> I will wait a few more days for pmartino to say something (please do if
>> you are reading this) and then I will probably fork bibus into github as
>> bibus-ng.
>>
>> I will also try to gather some support from the bibus using community in
>> archlinux (I am the maintainer for bibus there).
>>
>> If anyone else reading this is interested in contributing, please don't
>> be shy and introduce yourself - along with any ideas you might have for
>> this project.
>>
>> Cheers,
>>
>> Francisco
>

Re: [Bibus-biblio-users] The Future of Bibus

[Jan B. <ja...@be...>]

Hello,

I contacted Pierre privately and it turned out that some email trouble
prevented him from receiving the mails in this thread. I hope, this is
sorted out now and this mail will reach him, so he will be able to reply
correctly in the thread.

As bibus maintainer in Debian, I would strongly prefer not forking bibus, if
this is possible. I fear, that this would result in confusion and turn out
bad for everybody.
But Pierre will probably tell us some more details on the status of bibus
himself...

Best regards,
Jan

Und es begab sich am 04.07.2013 10:56, dass Francisco Pina Martins schrieb:
> Thank you Jonathan, for the feedback,
> 
> This is exactly what I mean. Not just a port of Bibus to a newer 
> framework, but also improve on it's shortcomings and add new features if 
> required.
> 
> At this point I think we should start thinking about a 'roadmap' of some 
> sort.
> We should also pick a new toolkit to draw the GUI and start gathering 
> more people to this effort, because honestly I don't think 2 people in 
> part time can pull this off in a reasonable amount of time.
> 
> I will wait a few more days for pmartino to say something (please do if 
> you are reading this) and then I will probably fork bibus into github as 
> bibus-ng.
> 
> I will also try to gather some support from the bibus using community in 
> archlinux (I am the maintainer for bibus there).
> 
> If anyone else reading this is interested in contributing, please don't 
> be shy and introduce yourself - along with any ideas you might have for 
> this project.
> 
> Cheers,
> 
> Francisco


-- 
Jan Beyer				happy Debian Maintainer	;-)	

mail	ja...@be...			GPG key ID 0x0CA6B4AA
jabber	bea...@ja...
web	http://www.beathovn.de/

Re: [Bibus-biblio-users] The Future of Bibus

[Francisco P. M. <f.p...@gm...>]

Thank you Jonathan, for the feedback,

This is exactly what I mean. Not just a port of Bibus to a newer 
framework, but also improve on it's shortcomings and add new features if 
required.

At this point I think we should start thinking about a 'roadmap' of some 
sort.
We should also pick a new toolkit to draw the GUI and start gathering 
more people to this effort, because honestly I don't think 2 people in 
part time can pull this off in a reasonable amount of time.

I will wait a few more days for pmartino to say something (please do if 
you are reading this) and then I will probably fork bibus into github as 
bibus-ng.

I will also try to gather some support from the bibus using community in 
archlinux (I am the maintainer for bibus there).

If anyone else reading this is interested in contributing, please don't 
be shy and introduce yourself - along with any ideas you might have for 
this project.

Cheers,

Francisco

On 03/07/13 14:03, Jonathan Schultz wrote:
> Hi Francisco and friends,
>
> Thank you for the update.
>
> I have to admit that since finishing my magnum opus (aka PhD thesis) I 
> haven't tried to use Bibus with LibreOffice, though I still use it to 
> keep my list of references. But I will need it or something similar 
> again in the future and would very much like to see it maintained. I 
> also have fair programming/hacking skills and could probably help you 
> to migrate it to python3 as you describe.
>
> That's the positive. The negative is that bibus has some serious 
> failings for my purposes, notably its inability to do Cambridge style 
> (footnotes) referencing adequately. I had some discussion with 
> pmartino but my needs were urgent so in the end I made a series of 
> hacks that work for me. One of these is to 'outsource' the formatting 
> of references to an external script as I just found it impossible to 
> describe the intricacies of formatting using the options that bibus 
> provides, or could be made to provide.
>
> So what I am saying is that I am happy to invest some time in keeping 
> bibus alive, but would like to take the opportunity to revisit some of 
> these issues, at least in a minimal way to begin with.
>
> Cheers,
> Jonathan
>
>
> On 03/07/13 19:37, Francisco Pina Martins wrote:
>> Hello everyone.
>>
>> I know this list is not being used often. In fact, most of the bibus
>> sourceforge page now looks like an abandoned house, but it is still my
>> favourite bibliography manager.
>>
>> As you may have noticed (or not, depending on your usage of bibus), the
>> program is no longer working with libreoffice. This is due to
>> libreoffice having been ported to python3, whereas bibus is written in
>> python2.
>>
>> Porting the "core" of the program should not be a difficult task, as
>> "2to3" should take care of that with minimal hassle.
>>
>> However, the fact that bibus uses wxpython should prove to be much more
>> of a challenge, since this toolkit has not yet been ported to python3.
>> (there is a project named "phoenix", but it is not yet complete, and
>> brings many changes to the API).[1]
>>
>>   From here forward, there are a few things that can happen.
>>
>> a) nothing happens. bibus will eventually fade into a broken piece of
>> software;
>> b) pmartino steps back up and put everything in gear (although I wish
>> for this, I don't think it's going to happen);
>> b) someone picks it up and puts it up to par with current technologies.
>> This will involve porting to python3 and eventually to a different
>> toolkit; eventually the project may have to be forked;
>>
>> I would pretty much like to continue using it, but that will require *a
>> lot* of work, that I simply cannot pull on my own. I know we are all
>> busy, but I think that with a few people on board we can pull this off.
>>
>> I guess what I am asking is:
>> Who is willing to help me out with this? I would do it on my own, but
>> bibus is a very large project for me to undertake alone.
>>
>> Thank you for your attention,
>>
>> Francisco Pina Martins
>>
>>
>> [1] http://wiki.wxpython.org/ProjectPhoenix
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bibus-biblio-users mailing list
>> Bib...@li...
>> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users

Re: [Bibus-biblio-users] The Future of Bibus

[Jonathan S. <jon...@im...>]

Hi Francisco and friends,

Thank you for the update.

I have to admit that since finishing my magnum opus (aka PhD thesis) I 
haven't tried to use Bibus with LibreOffice, though I still use it to 
keep my list of references. But I will need it or something similar 
again in the future and would very much like to see it maintained. I 
also have fair programming/hacking skills and could probably help you to 
migrate it to python3 as you describe.

That's the positive. The negative is that bibus has some serious 
failings for my purposes, notably its inability to do Cambridge style 
(footnotes) referencing adequately. I had some discussion with pmartino 
but my needs were urgent so in the end I made a series of hacks that 
work for me. One of these is to 'outsource' the formatting of references 
to an external script as I just found it impossible to describe the 
intricacies of formatting using the options that bibus provides, or 
could be made to provide.

So what I am saying is that I am happy to invest some time in keeping 
bibus alive, but would like to take the opportunity to revisit some of 
these issues, at least in a minimal way to begin with.

Cheers,
Jonathan


On 03/07/13 19:37, Francisco Pina Martins wrote:
> Hello everyone.
>
> I know this list is not being used often. In fact, most of the bibus
> sourceforge page now looks like an abandoned house, but it is still my
> favourite bibliography manager.
>
> As you may have noticed (or not, depending on your usage of bibus), the
> program is no longer working with libreoffice. This is due to
> libreoffice having been ported to python3, whereas bibus is written in
> python2.
>
> Porting the "core" of the program should not be a difficult task, as
> "2to3" should take care of that with minimal hassle.
>
> However, the fact that bibus uses wxpython should prove to be much more
> of a challenge, since this toolkit has not yet been ported to python3.
> (there is a project named "phoenix", but it is not yet complete, and
> brings many changes to the API).[1]
>
>   From here forward, there are a few things that can happen.
>
> a) nothing happens. bibus will eventually fade into a broken piece of
> software;
> b) pmartino steps back up and put everything in gear (although I wish
> for this, I don't think it's going to happen);
> b) someone picks it up and puts it up to par with current technologies.
> This will involve porting to python3 and eventually to a different
> toolkit; eventually the project may have to be forked;
>
> I would pretty much like to continue using it, but that will require *a
> lot* of work, that I simply cannot pull on my own. I know we are all
> busy, but I think that with a few people on board we can pull this off.
>
> I guess what I am asking is:
> Who is willing to help me out with this? I would do it on my own, but
> bibus is a very large project for me to undertake alone.
>
> Thank you for your attention,
>
> Francisco Pina Martins
>
>
> [1] http://wiki.wxpython.org/ProjectPhoenix
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bibus-biblio-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibus-biblio-users

[Bibus-biblio-users] The Future of Bibus

[Francisco P. M. <f.p...@gm...>]

Hello everyone.

I know this list is not being used often. In fact, most of the bibus 
sourceforge page now looks like an abandoned house, but it is still my 
favourite bibliography manager.

As you may have noticed (or not, depending on your usage of bibus), the 
program is no longer working with libreoffice. This is due to 
libreoffice having been ported to python3, whereas bibus is written in 
python2.

Porting the "core" of the program should not be a difficult task, as 
"2to3" should take care of that with minimal hassle.

However, the fact that bibus uses wxpython should prove to be much more 
of a challenge, since this toolkit has not yet been ported to python3. 
(there is a project named "phoenix", but it is not yet complete, and 
brings many changes to the API).[1]

 From here forward, there are a few things that can happen.

a) nothing happens. bibus will eventually fade into a broken piece of 
software;
b) pmartino steps back up and put everything in gear (although I wish 
for this, I don't think it's going to happen);
b) someone picks it up and puts it up to par with current technologies. 
This will involve porting to python3 and eventually to a different 
toolkit; eventually the project may have to be forked;

I would pretty much like to continue using it, but that will require *a 
lot* of work, that I simply cannot pull on my own. I know we are all 
busy, but I think that with a few people on board we can pull this off.

I guess what I am asking is:
Who is willing to help me out with this? I would do it on my own, but 
bibus is a very large project for me to undertake alone.

Thank you for your attention,

Francisco Pina Martins


[1] http://wiki.wxpython.org/ProjectPhoenix

[Bibus-biblio-users] New User: Entering Subjects For References

[Rich S. <rsh...@ap...>]

   I've looked at the docs (running 1.5.1 on Slackware) and do not see where
I can assign search keys for each reference. These keys would allow me to
find all references for 'stream,' 'benthos,' 'data analysis,' etc. Where
does bibus allow me to create these keys and assign multiple keys to each
item in the database?

TIA,

Rich

[Bibus-biblio-users] Your software Bibus

[<ed...@so...>]

Dear developers,

I am writing you regarding your software Bibus.

This is Ronny Gey and I am the admin of the website
http://www.sosciso.de - Social Science Software. I added your software
in our database and would like to inform you with this mail.

Please, see here the details on your software:
http://www.sosciso.de/en/software/ubersicht/?wctsort=lizenz&wctstart=1&&wcteid=6

If you have further questions, please feel free to contact me.

Best regards,
Ronny Gey
-- 
[SoSciSo] [http://www.sosciso.de]

[:de] Der Blog zu Software im sozialwissenschaftlichen Forschungsprozess
[:en] The blog about software in the social science research process

Re: [Bibus-biblio-users] Small useful patch for bibus

[Jan B. <ja...@be...>]

Hi Jonathan,

you could put the patch online into the patch tracker:
http://sourceforge.net/tracker/?group_id=110943&atid=657834

>From time to time, Pierre may show up and integrate something into bibus
codebase. (I hope.)
Otherwise I could also submit it to CVS. But I actually would prefer Pierre
or at least somebody else to give some comment first. Do you think, there
could possibly be any side effects?

Best regards,
Jan

Und es begab sich am 18.04.2012 07:56, dass Jonathan Schultz schrieb:
> Hello,
> 
> I hope someone gets this message. Pierre Martineau seems to have left 
> the room.
> 
> Anyway I have found a simple improvement for Bibus. It helps with a 
> problem caused by SQLite's default limitation of a maximum expression 
> depth of 1000. With a large file containing over 1000 references it was 
> not possible to show the Cited references in Bibus because of this 
> limitation. But because many of the references were duplicated it was 
> possible to make it work by filtering out duplicates before constructing 
> the SQL 'WHERE' expression.
> 
> I simply modified a few lines in OOoSelectCit in BibFrame.py:
> 
>>     def OOoSelectCit(self,order,short=False):
>>         """Return list of references cited in the current OOo document"""
>>         if not self.__connectToWriter(): return ()
>>         # See http://stackoverflow.com/questions/480214/how-do-you-remove-duplicates-from-a-list-in-python-whilst-preserving-order
>>         seen = set()
>>         seen_add = seen.add
>>         citations = [ref.Identifier for ref in self.doc if ref.Identifier not in seen and not seen_add(ref.Identifier)]
>>         return     self.__Identifiers2References(citations,order,short)[1]
> 
> Cheers,
> Jonathan


-- 
Jan Beyer				happy Debian Maintainer	;-)	

mail	ja...@be...			GPG key ID 0x0CA6B4AA
jabber	bea...@ja...
web	http://www.beathovn.de/

Re: [Bibus-biblio-users] Small useful patch for bibus

[Jan B. <ja...@be...>]

Hi Jonathan,

thanks for the patch. If you like, you could also put the patch online into
the patch tracker:
http://sourceforge.net/tracker/?group_id=110943&atid=657834

I have the impression, that this is more often looked at than the mailing
list. Then others could benefit from your work - even before it gets
integrated into bibus.

I could submit it to CVS. But I actually would prefer Pierre or at least
somebody else to give some comment first. Do you think, there could possibly
be any side effects?

Best regards,
Jan

Und es begab sich am 18.04.2012 07:56, dass Jonathan Schultz schrieb:
> Hello,
> 
> I hope someone gets this message. Pierre Martineau seems to have left 
> the room.
> 
> Anyway I have found a simple improvement for Bibus. It helps with a 
> problem caused by SQLite's default limitation of a maximum expression 
> depth of 1000. With a large file containing over 1000 references it was 
> not possible to show the Cited references in Bibus because of this 
> limitation. But because many of the references were duplicated it was 
> possible to make it work by filtering out duplicates before constructing 
> the SQL 'WHERE' expression.
> 
> I simply modified a few lines in OOoSelectCit in BibFrame.py:
> 
>>     def OOoSelectCit(self,order,short=False):
>>         """Return list of references cited in the current OOo document"""
>>         if not self.__connectToWriter(): return ()
>>         # See http://stackoverflow.com/questions/480214/how-do-you-remove-duplicates-from-a-list-in-python-whilst-preserving-order
>>         seen = set()
>>         seen_add = seen.add
>>         citations = [ref.Identifier for ref in self.doc if ref.Identifier not in seen and not seen_add(ref.Identifier)]
>>         return     self.__Identifiers2References(citations,order,short)[1]
> 
> Cheers,
> Jonathan


-- 
Jan Beyer				happy Debian Maintainer	;-)	

mail	ja...@be...			GPG key ID 0x0CA6B4AA
jabber	bea...@ja...
web	http://www.beathovn.de/

[Bibus-biblio-users] Small useful patch for bibus

[Jonathan S. <jon...@im...>]

Hello,

I hope someone gets this message. Pierre Martineau seems to have left 
the room.

Anyway I have found a simple improvement for Bibus. It helps with a 
problem caused by SQLite's default limitation of a maximum expression 
depth of 1000. With a large file containing over 1000 references it was 
not possible to show the Cited references in Bibus because of this 
limitation. But because many of the references were duplicated it was 
possible to make it work by filtering out duplicates before constructing 
the SQL 'WHERE' expression.

I simply modified a few lines in OOoSelectCit in BibFrame.py:

>     def OOoSelectCit(self,order,short=False):
>         """Return list of references cited in the current OOo document"""
>         if not self.__connectToWriter(): return ()
>         # See http://stackoverflow.com/questions/480214/how-do-you-remove-duplicates-from-a-list-in-python-whilst-preserving-order
>         seen = set()
>         seen_add = seen.add
>         citations = [ref.Identifier for ref in self.doc if ref.Identifier not in seen and not seen_add(ref.Identifier)]
>         return     self.__Identifiers2References(citations,order,short)[1]

Cheers,
Jonathan

[Bibus-biblio-users] Bibus 1.5.1: Changing computer and windows OS: 7

[Stefano P. <st...@ka...>]

Can anybody help?
Is seams upgrade is impossible:

I use Bibus since many years now probably 2001:  Version 2, June 1991 (help
doesn't show which vers is)

I am changing computer from windows XP to 7

I followed the instructions to install Bibus 1.5.1 in
http://bibus-biblio.sourceforge.net/wiki/index.php/Installation

After converting my references there is nothing in the new data base
although the size of both is roughly the same ca 9.6MB

Should I go back to older versions without the different Python intermediate
installations?

Up to which version there is still compatibility with the older database?

Android:
SQL lite data base can also be viewed in Adroid?
Would it work also the new 1.5.1 version?

Thanks a lot

Stefano

[Bibus-biblio-users] bibus: Finalizing Word document trouble

[Jan B. <ja...@be...>]

Bonsoir Pierre,

unfortunately, I have to use MS Word to write a paper. And I ran into the 
following error message:

Error for Res =  

Error for Code =   EMBED Equation.3
Traceback (most recent call last):
   File "C:\Program Files\bibus\BibFrame.py", line 2062, in
onMenuMSWFinalize
     aDoc.fuseCitations(aDoc.application.ActiveDocument.Fields)
   File "C:\Program Files\bibus\mswDoc.py", line 307, in fuseCitations
     self.mswFormatter.fuseCitations(mFields)
   File "C:\Program Files\bibus\bibMSW\mswFormatter.py", line 934, in
fuseCitations
     citationGroups = self.__groupCitations(mswFields)
   File "C:\Program Files\bibus\bibMSW\mswFormatter.py", line 1213, in
__groupCitations
     codeText = sortedCitationGroupInfo[grNb][citeNb][1]
IndexError: list index out of range

After some tests I suspect, that there is a problem when citations are 
inserted just before a formula, separated by only a whitespace. It already 
helps to replace this whitespace by a non-breaking whitespace. Or just one 
more word. But somehow it seems, that some bibus code gets confused, when 
there is a citation followed by a whitespace followed by a formula.

Do you maybe have some idea on that one? (Where does the "Error for Code = 
EMBED Equation.3" come from?)

Many thanks!

Best Regards,
Jan

-- 
Jan Beyer
Functional Electronic Materials
Department of Physics, Chemistry and Biology IFM
Linköping university
SE-581 83 Linköping, Sweden

mail            be...@if...
GPG-key ID      0x1B48196F
phone           +46 13 28 5775
office          F:E210