Re: Interest in Volunteering With the OpenOffice Project
Welcome Tyler! For MSAA/IA2 bugs, please check the ia2 meta issuehttps://issues.apache.org/ooo/show_bug.cgi?id=121767 firstly, and please feel free to ask anything that you interested. On Tue, Jan 7, 2014 at 5:00 PM, Jürgen Schmidt jogischm...@gmail.comwrote: Hi Tyler, that sounds good and welcome at Apache OpenOffice. This is a mailing list and if you are interested in more information you can subscribe to this list by sending an email to dev-subscr...@openoffice.apache.org (you are currently not subscribed). More interesting for you is potentially the q...@openoffice.apache.org mailing list where QA relevant topics are discussed and where is less traffic. But you are welcome on all list. You can try our latest snapshot build for Windows and en-US which have integrated all the IAccessible2 enhancements from http://ci.apache.org/projects/openoffice/install/winsnap/Apache_OpenOffice_4.1.0_Win_x86_install_en-US.exe_1554003.exe . Try to install and check out the IAccessible 2 support. For more detailed question I recommend the qa mailing list. Again welcome at OpenOffice and thanks for your interest to help us with the accessibility testing to make AOO available to even more people. Your help is highly appreciated. Kind regards Juergen On 1/6/14 3:09 AM, Tyler Kavanaugh wrote: Hello all: My name is Tyler Kavanaugh, and I am from Kansas, in the United States. I would very much like to be a part of the OpenOffice project, with a focus on QA/accessibility, as I am a blind user who uses screen-access software to accomplish everyday tasks on the computer. I am aware that the product recently (as of November or December 2013) finished its implementation of MSAA/IAccessible2, and this has piqued my interest. Where would you all suggest that I start? Thanks, -Tyler - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Best Regards, Steve Yin
Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
Raymond and I remain stuck on the last issue that we wrote to you about. We
would like to better encapsulate our problem and see if you might be able to
provide more clarification on what we might be able to try.
1.We have performed a directory clean and restarted the build --all
process from the beginning with the debug flag set. This time we are not
using the multi-processing commands.
2.The build process proceeds without error, even compiling all the files
up to the svx module.
3.When the svx module is finished compiling and the LNK of the
Library/libsvxcore.so is being performed the process stops with an Undefined
symbol linking error.
4.The symbol is ParagraphDataParagraphData::operator(const
ParagraphData) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
5.Since the ParagraphData didn't appear in e3dundo neither did the
OutlinerParaObject, I was at a loss for this linking error, but there was an
#include editeng/outlobj.hxx. Since that is the location of
OutlinerParaObject, I have commented out that include to see what would
happen. The result is the system still compiled, but the linking failed
again, this time in another location.
6.The new location that we got the same Undefined symbol error link
message on was in the file sdrlinefillshadowtextattribute.o located in the
attribute directory. This time I was unable to find a #include
editeng/outlobj.hxx in either the header or source file. However
sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which
includes sdrtextattribute.
7.sdrtextattribute was the first location we have found where the
OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we
had not found this object before (at least in the path that was failing),
this was the first thing that made some sense in this problem.
8.We have reviewed your last email, but are having a difficult time
understanding what you recommended. It appeared you were recommending we
modify the OutlinerParaObject constructor, but how? You wanted us to remove
the ParagraphDataVector parameter? Or did you want us to create a different
constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of
needing a ParagraphDataVector symbol. Does this patch work for you? Since this
makes svx binary incompatible with its original you need to do a build
--prepare --from svx when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
-OutlinerParaObject(
-const EditTextObject rEditTextObject,
-const ParagraphDataVector rParagraphDataVector =
ParagraphDataVector(),
-bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject, const ParagraphDataVector,
bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject);
OutlinerParaObject(const OutlinerParaObject rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject
rEditTextObject, co
{
}
+OutlinerParaObject::OutlinerParaObject( const EditTextObject)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject(
rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
9.Also even after all of this, do you think that if we modify the
OutlinerParaObject that the rest of the svx will link correctly and that all
these errors we have seen from this problem resulted from an error in the
OutlinerParaObject and our compiler?
I sure hope so ;-)
Once again, thanks for all your help in advance.
You're welcome!
I hope you had a good holiday season. We look forward to hearing back from
you.
BTW: I'll also be away next week.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: space in wiki for documentation of branches
On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. why should we make a new place ? rgds jan I. Do we already have such pages/places (I looked for my aw080 branch, but noting in the new confluence wiki) and if not, should we create a place and add at least a descriptive page (which may contain just a short description) for each branch? If we want to do so, where could I add a first page for my new branch and start to document it? Any suggestions? I am not aware of any place on the wiki that does this currently. We do have the README file in Subversion here: https://svn.apache.org/repos/asf/openoffice/README That gives a one line description of the branches. It looks like a some are missing as this hasn't been updated in a while. If you decide to put something on the wiki, maybe it would be a good idea to add a link to it in the README? -Rob Sincerely, Armin -- ALG - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: space in wiki for documentation of branches
On 1/8/14 3:09 PM, jan i wrote: On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. why should we make a new place ? no need of course, just a problem to find the hidden secrets in our nirvana ;-) Juergen rgds jan I. Do we already have such pages/places (I looked for my aw080 branch, but noting in the new confluence wiki) and if not, should we create a place and add at least a descriptive page (which may contain just a short description) for each branch? If we want to do so, where could I add a first page for my new branch and start to document it? Any suggestions? I am not aware of any place on the wiki that does this currently. We do have the README file in Subversion here: https://svn.apache.org/repos/asf/openoffice/README That gives a one line description of the branches. It looks like a some are missing as this hasn't been updated in a while. If you decide to put something on the wiki, maybe it would be a good idea to add a link to it in the README? -Rob Sincerely, Armin -- ALG - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Dictionary en_GB - 2014-01-01 - Test version
Hello! I am following Andrea's steps to try to release an updated version of the English (British) speller with over 800 unique words added by me (plus several dozens of derived words). This OXT includes all English dictionaries as before, with only the en_GB updated. I was told to place an unpublished version of it and send the link to the DEV ML in order for people to test it for one week and give feedback. If all is fine, it will be published. Please notice that I had some difficulty in getting the direct link, as I pressed the publish button for it to appear and then unpublished it again... not sure if the procedure was 100% the correct one. Here are the download links: Direct link: http://extensions.openoffice.org/en/download/17669 Test ODT #1 (simple): https://dl.dropboxusercontent.com/u/30674540/test_words_speller_20140108.odt Test ODT #2 (large): https://dl.dropboxusercontent.com/u/30674540/test_words_speller_20140107.odt For the reasons why I have decided to embrace this project, please read: http://marcoagpinto.cidadevirtual.pt/en_GB_README.html Happy testing! Kind regards from, Marco A.G.Pinto --- --
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On 1/8/2014 4:32 AM, Herbert Duerr wrote: On 08.01.2014 01:09, Kay Schenk wrote: [...] Given your recent commits as patches to (now suppiled) boost_1.55, AND some interesting definitions in /main/stlport/systemstl/slist #else // fall back to boost/tr1 (forward_list or plain list) #include boost/config.hpp (who knows if the suppiled config.hpp jives with my own) The config.hpp provided by boost must match with the rest of the library. At least that's what this header is intended for. I ditched using my local boost_1.54, and things are going much much better. Not quite there yet but close. :} Yay! At this point, given the customized work you've done, we might think of warning folks against using their local boost versions -- at least put some notes in configure.in. Just a thought. We should add such a warning to about every system library that is not regularly enabled for building and testing. The release builds prefer the defaults, but for many libraries AOO's configure script allows the use of system provided alternatives: apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit, curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg, libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib. Assuming that each of the above mentioned libraries have 4 to 12 different versions out in the wild this means that between 4^40 and 12^40 different configurations are possible, of which we build and test only very few (=4?) regularly. The configuration space is increased even more when we consider that there are many different kinds of compilers in different versions, also linkers etc. What would be the simplest approach to address this? Just adding a use the --with-system-X options only if you know that this works or if you enjoy debugging? Or should we hide them behind an --enable-expert-options configure switch which would be similar to the broad --enable-category-b option? For my part, I'd suggest we hide them behind a --enable-expert-options switch. Given the massive number of configurations, doing such a thing could alleviate many headaches, especially given that it could be extremely difficult for some of us to reproduce and track down problems related to very specific library, compiler, and linker versions. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: space in wiki for documentation of branches
On 08.01.2014 07:50, Jürgen Schmidt wrote: On 1/8/14 3:09 PM, jan i wrote: On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. why should we make a new place ? no need of course, just a problem to find the hidden secrets in our nirvana ;-) Juergen Yes, thats why I am asking. I could not really find it, so a place in the confluence wiki would be better. I think this would fit perfectly somewhere in the development planning area so that everyone interested could find what is worked on and evtl. gets even motivated to step in. Isnt that the place people look at when they try to find out what is going on? I would be ready to document my existing branches in brief and extensively for new ones. An initial page per branch and maybe a short description would be enough as a minimum (maybe autogenerated when someone creates a branch in trunk, adding creation date and creator...just dreaming). In that form it may also give a preview of what may be coming to the next versions (without forcing it, it should be train model based). E.g. with accessibility when it would have been documented there it would be more clear where it comes from, evtl. how far it is progressed and if it will be in one of the next versions (e.g. include a single 'progress' percent number). Kay, I guess you are the one who could prepare a place for these (if we agree to do so)...? rgds jan I. Do we already have such pages/places (I looked for my aw080 branch, but noting in the new confluence wiki) and if not, should we create a place and add at least a descriptive page (which may contain just a short description) for each branch? If we want to do so, where could I add a first page for my new branch and start to document it? Any suggestions? I am not aware of any place on the wiki that does this currently. We do have the README file in Subversion here: https://svn.apache.org/repos/asf/openoffice/README That gives a one line description of the branches. It looks like a some are missing as this hasn't been updated in a while. If you decide to put something on the wiki, maybe it would be a good idea to add a link to it in the README? -Rob Sincerely, Armin -- ALG - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: space in wiki for documentation of branches
Hi, Armin Le Grand schrieb: On 08.01.2014 07:50, Jürgen Schmidt wrote: On 1/8/14 3:09 PM, jan i wrote: On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. That contains some general information. There I would only add a link to the page with more details about a specific branch. why should we make a new place ? no need of course, just a problem to find the hidden secrets in our nirvana ;-) Without search engine everyone is lost. There exist for example already the description of /openoffice/branches/alg/aw080 on https://wiki.openoffice.org/wiki/Aw080_documentation Juergen Yes, thats why I am asking. I could not really find it, so a place in the confluence wiki would be better. I think this would fit perfectly somewhere in the development planning area so that everyone interested could find what is worked on and evtl. gets even motivated to step in. Isnt that the place people look at when they try to find out what is going on? I would be ready to document my existing branches in brief and extensively for new ones. An initial page per branch and maybe a short description would be enough as a minimum (maybe autogenerated when someone creates a branch in trunk, adding creation date and creator...just dreaming). I would like to keep it in MWiki. Infos about AW080 is there and pages of past, larger developments are also in Mwiki. In that form it may also give a preview of what may be coming to the next versions (without forcing it, it should be train model based). E.g. with accessibility when it would have been documented there it would be more clear where it comes from, evtl. how far it is progressed and if it will be in one of the next versions (e.g. include a single 'progress' percent number). Kay, I guess you are the one who could prepare a place for these (if we agree to do so)...? The start page of MWiki has some outdated informations right top. Rework there is necessary anyway. So I suggest putting a link list of actual development activities there, put each content under a meaningfule title in the MWiki, tag it with category Development, and trust the search engines. Kind regards Regina [..] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Creation of MWiki Account is Impossible For A Blind User
On 8 January 2014 19:14, Tyler Kavanaugh tw...@kc.rr.com wrote: Hello all: As suggested in the new contributor orientation, I went to attempt to create an account for MWiki. However, I can't complete the process because the CAPTCHA that is used does not provide any alternative (audio, text question, etc). How should I proceed, and is there someone I can contact to get an account set up? you are in the right place and I am sure someone will help create your account. Actually every picture has a tooltip that should help you to the information you need. rgds jan I. Thanks. -Tyler - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Creation of MWiki Account is Impossible For A Blind User
Tyler Kavanaugh wrote: As suggested in the new contributor orientation, I went to attempt to create an account for MWiki. However, I can't complete the process because the CAPTCHA that is used does not provide any alternative (audio, text question, etc). How should I proceed, and is there someone I can contact to get an account set up? It's actually difficult for everyone, due to other reasons: most browser do not handle it correctly and it's on the list of maintenance actions to do on the MWiki. In the meantime, just give me your preferred username and I'll create an account for you. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@apache.org wrote: On 08.01.2014 01:09, Kay Schenk wrote: [...] Given your recent commits as patches to (now suppiled) boost_1.55, AND some interesting definitions in /main/stlport/systemstl/slist #else // fall back to boost/tr1 (forward_list or plain list) #include boost/config.hpp (who knows if the suppiled config.hpp jives with my own) The config.hpp provided by boost must match with the rest of the library. At least that's what this header is intended for. yes...but if a developer is using a local boost, might they inadvertently include some config options that might not be compatible with OpenOffice's build process? This was my concern when I saw this. I ditched using my local boost_1.54, and things are going much much better. Not quite there yet but close. :} Yay! yes, got a good build! YAY! Indeed! At this point, given the customized work you've done, we might think of warning folks against using their local boost versions -- at least put some notes in configure.in. Just a thought. We should add such a warning to about every system library that is not regularly enabled for building and testing. The release builds prefer the defaults, but for many libraries AOO's configure script allows the use of system provided alternatives: apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit, curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg, libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib. Assuming that each of the above mentioned libraries have 4 to 12 different versions out in the wild this means that between 4^40 and 12^40 different configurations are possible, of which we build and test only very few (=4?) regularly. The configuration space is increased even more when we consider that there are many different kinds of compilers in different versions, also linkers etc. What would be the simplest approach to address this? Just adding a use the --with-system-X options only if you know that this works or if you enjoy debugging? Or should we hide them behind an --enable-expert-options configure switch which would be similar to the broad --enable-category-b option? Your analysis above is well-taken. And, dealing with configure options, which local configure options might be helpful, and which ones might be more challenging, is an interesting question. These are topics that should be discussed in a new thread, I think. I know we all want developers to have a good experience and providing more clarification on how the configure options effect the outcome will certainly help. Thanks again for all your help with my build problems... Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: space in wiki for documentation of branches
On 8 January 2014 16:16, Armin Le Grand armin.le.gr...@me.com wrote: On 08.01.2014 07:50, Jürgen Schmidt wrote: On 1/8/14 3:09 PM, jan i wrote: On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. why should we make a new place ? no need of course, just a problem to find the hidden secrets in our nirvana ;-) Juergen Yes, thats why I am asking. I could not really find it, so a place in the confluence wiki would be better. I think this would fit perfectly somewhere in the development planning area so that everyone interested could find what is worked on and evtl. gets even motivated to step in. Isnt that the place people look at when they try to find out what is going on? I would be ready to document my existing branches in brief and extensively for new ones. An initial page per branch and maybe a short description would be enough as a minimum (maybe autogenerated when someone creates a branch in trunk, adding creation date and creator...just dreaming). please be aware that cwiki is not nearly as visited as mwiki, so putting it in cwiki is a real good hiding place. In that form it may also give a preview of what may be coming to the next versions (without forcing it, it should be train model based). E.g. with accessibility when it would have been documented there it would be more clear where it comes from, evtl. how far it is progressed and if it will be in one of the next versions (e.g. include a single 'progress' percent number). I dont object to the idea, but do we really want to that much red tape around using branches. I would for sure remove capstone/l10n40 and keep it local instead if I have to document in cwiki. please remember the more documentation (in, at least to me, and unkown wiki language) makes it more likely that people considering a branch stop the idea. Kay, I guess you are the one who could prepare a place for these (if we agree to do so)...? rgds jan I. Do we already have such pages/places (I looked for my aw080 branch, but noting in the new confluence wiki) and if not, should we create a place and add at least a descriptive page (which may contain just a short description) for each branch? If we want to do so, where could I add a first page for my new branch and start to document it? Any suggestions? I am not aware of any place on the wiki that does this currently. We do have the README file in Subversion here: https://svn.apache.org/repos/asf/openoffice/README That gives a one line description of the branches. It looks like a some are missing as this hasn't been updated in a while. If you decide to put something on the wiki, maybe it would be a good idea to add a link to it in the README? -Rob Sincerely, Armin -- ALG - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [LAZY CONSENSUS] maintenance of ooo-wiki2-vm.a.o and ooo-forums.a.o
Hi. Now that the whole vm-team has replied, and there has been no -1, I assume we can proceed. Unless someone objects, fast, I will proceed with the following steps: - prepare a plan for changes in mwiki/forums - ask infra to adjust the karma for vm-team members, according to the agreed roles - implement changes rgds jan I. On 8 January 2014 18:17, imacat ima...@mail.imacat.idv.tw wrote: +1. Sorry I was overwhelmed by the mails. On 2014/01/07 00:52, Jürgen Schmidt said: On 12/29/13 4:09 PM, jan i wrote: top posting. A friendly reminder, this LAZY Consensus proposal runs until january 2nd. Until now, no -1 has been received. Andrea is the only team member that has given a +1 the other team members (jsc, imacat, arist) have not expressed any opinion yet. +1 for your proposal and I volunteer to help in vm-team. But mentioned some time ago I am lazy admin. Maybe we can find 1 or 2 further members who are interested to help. Anyway I will do my best to help where I can. Juergen Wish you all a happy new year. rgds jan I. On 28 December 2013 17:39, Andrew Pitonyak and...@pitonyak.org wrote: I have been following as best I can while traveling, and it is not my place to say, but I agree jan i j...@apache.org wrote: On 28 December 2013 16:19, Andrea Pescetti pesce...@apache.org wrote: On 22/12/2013 jan i wrote: based on a polite push from a good infra colleague, I have decided to present yet another proposal for maintaining ooo-wiki2-vm.a.o and ooo-forums.a.o I agree with the proposal, so +1 from me. The main value it brings is that we will have a common (and lightweight) set of rules that allow us to establish some initial guidelines. This will make it easier to include new volunteers later, or promote existing volunteers to sysadmin role, or do whatever we agree upon, at due time. But we need an initial set of guidelines to work effectively as a team. thanks for your +1, thats the first of the existing team, I still hope the rest of the team will join. The intention of the proposal is NOT to exclude anybody, it (as andrea write very nicely) to make a basis on which we can build, while securing our servers. I suggest myself for sysadm, and jsc, pescetti, arist and imacat for vm-team. Of course my suggestion depends on the willingness of the mentioned people. I'm willing to be part of team as proposed. thx, your input and help is much valued. Remember there are 3 days left of this year, if you have something to catch up on. rgds jan I. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/
Re: Creation of MWiki Account is Impossible For A Blind User
On 1/8/2014 12:46 PM, jan i wrote: On 8 January 2014 19:14, Tyler Kavanaugh tw...@kc.rr.com wrote: [...] you are in the right place and I am sure someone will help create your account. Actually every picture has a tooltip that should help you to the information you need. Those tooltips (provided by the alt attribute of the img element) are nonsensical. All they are is a hexadecimal GUID for the image itself. rgds jan I. Thanks. -Tyler - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Interest in Volunteering With the OpenOffice Project
On Sun, Jan 5, 2014 at 9:09 PM, Tyler Kavanaugh tw...@kc.rr.com wrote: Hello all: My name is Tyler Kavanaugh, and I am from Kansas, in the United States. I would very much like to be a part of the OpenOffice project, with a focus on QA/accessibility, as I am a blind user who uses screen-access software to accomplish everyday tasks on the computer. I am aware that the product recently (as of November or December 2013) finished its implementation of MSAA/IAccessible2, and this has piqued my interest. Where would you all suggest that I start? Hi Tyler, welcome to the project. Others have already sent you some good info. At the risk of overloading you with info, here's another resource you might want to review, our New Volunteer Orientation modules: http://openoffice.apache.org/orientation/ For QA specifically there is this orientation module: http://openoffice.apache.org/orientation/intro-qa.html It has some useful information on bug handling and will lead you to sign up for a Bugzilla account, etc. Regards, -Rob Thanks, -Tyler - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Hey Herbert, Thanks for the quick response and your fix worked. The svx module built perfectly. I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer. While rebuilding the sw module, the build of the fmtatr2 file failed. The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file Could not find a match for std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::auto_ptr_refstd::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange::_TypeU(std::auto_ptrconststd::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange, const std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange *) needed in std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::operator std::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRangeconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange () Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously? Thanks, David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, January 08, 2014 4:06 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Hi David, On 07.01.2014 23:11, Steele, Raymond wrote: Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try. 1.We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands. 2.The build process proceeds without error, even compiling all the files up to the svx module. 3.When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an Undefined symbol linking error. 4.The symbol is ParagraphDataParagraphData::operator(const ParagraphData) and it used to complain about this file in the e3dundo.o. Wasn't it complaining about a missing ParagraphDataVector symbol originally? 5.Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include editeng/outlobj.hxx. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location. 6.The new location that we got the same Undefined symbol error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include editeng/outlobj.hxx in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute. 7.sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem. 8.We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like? I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx binary incompatible with its original you need to do a build --prepare --from svx when you apply it. ---
Problems at the Beginning of the Windows Build
I've just finished configuring and bootstrapping the Windows build of OpenOffice (from the head revision on trunk). I changed to aoo/main/instsetoo_native, and ran: build -P2 -- -P2 However, I run into an error at the very beginning: build -- version: 275224 = Building module instsetoo_native = Entering /cygdrive/i/aoo/main/instsetoo_native/inc_openoffice/windows/msi_languages /usr/bin/bash: I:/aoo/main/solver/410/wntmsci12.pro/bin/ulfconv: No such file or directory dmake: Error code 127, while making '../../../wntmsci12.pro/misc/win_ulffiles/ActionTe.mlf' ERROR: error 65280 occurred while making /cygdrive/i/aoo/main/instsetoo_native/inc_openoffice/windows/msi_languages Tyler@tyler-pc /cygdrive/i/aoo/main/instsetoo_native $ Did I do something wrong? The first time I tried to do the build, about an hour or so ago, I got errors relating to the use of carriage return/newline (\r\n) pairs, with Perl complaining that '\r' wasn't a valid command. (Keep in mind that my initial checkout was done using TortoiseSVN and not Cygwin). So I clobbered the whole checkout, redid it with the Cygwin svn client, then reconfigured and bootstrapped again. I remembered to source the winenv.set.sh file--did that prior to the call to ./bootstrap. -Tyler - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Would like to contribute
Hello, My name is Glenn Nelson and I'm from Kenosha, Wisconsin. I recently graduated the University of Management and Technology with an Associates degree in Computer Science in March of 2013 and am continuing with a Bachelors degree. I would like to contribute to Open Office by Testing or QA. Sincerely, Glenn Nelson
Re: Problems at the Beginning of the Windows Build
On 01/09/2014 01:28 AM, Tyler Kavanaugh wrote: I've just finished configuring and bootstrapping the Windows build of OpenOffice (from the head revision on trunk). I changed to aoo/main/instsetoo_native, and ran: build -P2 -- -P2 Also use the --all option, so that all dependencies of this final module are processed first, i.e. run build --all -P2 -- -P2 [...] The first time I tried to do the build, about an hour or so ago, I got errors relating to the use of carriage return/newline (\r\n) pairs, with Perl complaining that '\r' wasn't a valid command. (Keep in mind that my initial checkout was done using TortoiseSVN and not Cygwin). So I clobbered the whole checkout, redid it with the Cygwin svn client, then reconfigured and bootstrapped again. I remembered to source the winenv.set.sh file--did that prior to the call to ./bootstrap. Apparently cygwin's Subversion and Tortoise use different defaults for files without a svn:eol-style property (or with svn:eol-style=native). Keeping files as they are checked in when that property hasn't been set seems to be the default for cygwin's svn. Can Tortoise be configured to behave similarly? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On 01/08/2014 07:52 PM, Kay Schenk wrote: On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@apache.org wrote: [...] The config.hpp provided by boost must match with the rest of the library. At least that's what this header is intended for. yes...but if a developer is using a local boost, might they inadvertently include some config options that might not be compatible with OpenOffice's build process? This was my concern when I saw this. If the system boost version is new enough and its config.hpp matches to the rest of its headers then it should be possible to make AOO build with it. If there are platforms where the system boost's default configuration doesn't work for building AOO then AOO should be adapted for it. Patches for that situation should be integrated if they don't cause regressions for other platforms / the boost version AOO brings along. I ditched using my local boost_1.54, and things are going much much better. Not quite there yet but close. :} Yay! yes, got a good build! YAY! Indeed! :-) At this point, given the customized work you've done, we might think of warning folks against using their local boost versions -- at least put some notes in configure.in. Just a thought. We should add such a warning to about every system library that is not regularly enabled for building and testing. The release builds prefer the defaults, but for many libraries AOO's configure script allows the use of system provided alternatives: apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit, curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg, libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib. Assuming that each of the above mentioned libraries have 4 to 12 different versions out in the wild this means that between 4^40 and 12^40 different configurations are possible, of which we build and test only very few (=4?) regularly. The configuration space is increased even more when we consider that there are many different kinds of compilers in different versions, also linkers etc. What would be the simplest approach to address this? Just adding a use the --with-system-X options only if you know that this works or if you enjoy debugging? Or should we hide them behind an --enable-expert-options configure switch which would be similar to the broad --enable-category-b option? Your analysis above is well-taken. And, dealing with configure options, which local configure options might be helpful, and which ones might be more challenging, is an interesting question. These are topics that should be discussed in a new thread, I think. +1 I have to admit that I'm not an expert on autoconf, so I don't know whether we can make options disappear for e.g. a non-expert mode. But at least a better grouping of these options should be possible. I know we all want developers to have a good experience and providing more clarification on how the configure options effect the outcome will certainly help. +1 again Even people who worked for many years with the OpenOffice code often don't really know the exact impact of each configure switch. Many use their tried and working configure scripts and almost never deviate from that. E.g. for each of --with-system-X switches it is very hard to answer how enabling it would impact the build and the result, especially when X is available in a couple of different versions and configurations. But this might be an interesting opportunity for volunteers? E.g. when trying to figure out the impact of the --with-system-hunspell switch one could install one hunspell version after the other on the different platforms, do a clean build with each of them and test the install set. The experience gained from these iterations could result in a much improved description of such a configuration switch, which would be very much appreciated by everyone. Thanks again for all your help with my build problems... You're welcome! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: space in wiki for documentation of branches
On 1/8/14 7:57 PM, jan i wrote: On 8 January 2014 16:16, Armin Le Grand armin.le.gr...@me.com wrote: On 08.01.2014 07:50, Jürgen Schmidt wrote: On 1/8/14 3:09 PM, jan i wrote: On 8 January 2014 03:46, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Jan 7, 2014 at 4:34 PM, Rob Weir robw...@apache.org wrote: On Tue, Jan 7, 2014 at 7:19 PM, Armin Le Grand armin.le.gr...@me.com wrote: Hi List, I have added a new branch to the branches part of the repository. I thought it would be a good idea to have a place in the wiki to document what the branches are, what they intend to do and to have a central place to document what's going on there. For the new branch, I thought about documenting the state and ongoing work there, instead of adding a file and checking it in to svn, that would be in the way when later reintegrating the finished stuff. A VERY good idea...maybe a main heading -- Development Planning (or a name of your choosing) -- under Project Planning. Thanks for bringing this up...I was just wondering about some of the branches the other day. isnt that what we already have at https://wiki.openoffice.org/wiki/Source_Code here we have branches/tags etc documented. why should we make a new place ? no need of course, just a problem to find the hidden secrets in our nirvana ;-) Juergen Yes, thats why I am asking. I could not really find it, so a place in the confluence wiki would be better. I think this would fit perfectly somewhere in the development planning area so that everyone interested could find what is worked on and evtl. gets even motivated to step in. Isnt that the place people look at when they try to find out what is going on? I would be ready to document my existing branches in brief and extensively for new ones. An initial page per branch and maybe a short description would be enough as a minimum (maybe autogenerated when someone creates a branch in trunk, adding creation date and creator...just dreaming). please be aware that cwiki is not nearly as visited as mwiki, so putting it in cwiki is a real good hiding place. exactly, we should use mediawiki whenever possible, we could move the content from confluence to mediawiki to make it even more clear. Important pages will be monitored and wrong or damaging changes can be corrected. In that form it may also give a preview of what may be coming to the next versions (without forcing it, it should be train model based). E.g. with accessibility when it would have been documented there it would be more clear where it comes from, evtl. how far it is progressed and if it will be in one of the next versions (e.g. include a single 'progress' percent number). I dont object to the idea, but do we really want to that much red tape around using branches. I would for sure remove capstone/l10n40 and keep it local instead if I have to document in cwiki. please remember the more documentation (in, at least to me, and unkown wiki language) makes it more likely that people considering a branch stop the idea. it should be no must to document in detail but a short paragraph describing for what kind of work the branch in intended can help. And more documentation can help developers to organize their work or can help for collaboration to work with more people on the same branch. But again it should be no must if people lose interest because of the documentation burden. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
