Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
2013/4/16 Claudio Filho filh...@gmail.com: Sorry by my newbie understanding about the question. I am studing the requeriment to build into debian way, getting many problems to bring the code to be debianized, breaking in some parts (at this moment in pdfimport module) and to know more about this question can help. +1 I'm also trying. ;-) Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Err... Sorry but... the extentions cited by Ariel will be integrated in the source as code and not as extension? In other words, will be part of core? As he explained, make sense for me to merge this functions in the code in the same way of Solver was in the past. Sorry by my newbie understanding about the question. I am studing the requeriment to build into debian way, getting many problems to bring the code to be debianized, breaking in some parts (at this moment in pdfimport module) and to know more about this question can help. And thanks by share the final of this point. Bests, Claudio 2013/4/3 Jürgen Schmidt jogischm...@gmail.com On 3/27/13 3:23 PM, Ariel Constenla-Haile wrote: On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote: Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't have any problem at all. I don't think that it will help us if we react this way. I am not reacting. Please don't turn this into a circus like the one with the 0^0. Really nobody wanted that you revert anything here. I am no native English speaker, but for the content, and the tone, of Andre mails, I understood he wanted his extension back: I don't see why this change should be a good thing. I was hoping that I would find the time in the future to fix this Including the pre-bundled extensions into the core is a workaround not a fix. We are still able (well until your changes) to release the presenter console under Apache license I still don' t see the benefit of the change. [...] This is something that I have used several times in the past and always was very glad that I had it. And he got it back (together with the Presentation Minimizer, as it makes no sense to have one pre-registered extension and the other integrated). Again, I don't have any problem at all, nor then, nor now :) Just a short question before I lose it out of focus, do you plan to revert your revert? Or can/should we revert it? I really think it was a misunderstanding and nothing else. Juergen Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/27/13 3:23 PM, Ariel Constenla-Haile wrote: On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote: Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't have any problem at all. I don't think that it will help us if we react this way. I am not reacting. Please don't turn this into a circus like the one with the 0^0. Really nobody wanted that you revert anything here. I am no native English speaker, but for the content, and the tone, of Andre mails, I understood he wanted his extension back: I don't see why this change should be a good thing. I was hoping that I would find the time in the future to fix this Including the pre-bundled extensions into the core is a workaround not a fix. We are still able (well until your changes) to release the presenter console under Apache license I still don' t see the benefit of the change. [...] This is something that I have used several times in the past and always was very glad that I had it. And he got it back (together with the Presentation Minimizer, as it makes no sense to have one pre-registered extension and the other integrated). Again, I don't have any problem at all, nor then, nor now :) Just a short question before I lose it out of focus, do you plan to revert your revert? Or can/should we revert it? I really think it was a misunderstanding and nothing else. Juergen Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Tue, Mar 26, 2013 at 11:45:41PM +0100, Andrea Pescetti wrote: Ariel Constenla-Haile wrote: If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. In the case of dictionaries (which is anyway marginal with respect to the current discussion) I actually find that what OpenOffice is doing now, i.e., bundling them as extensions, is a good solution. I was talking about *how* they are packaged in the basis core-01 package. Before, they were packaged as single packages. You can find the remaining of this under trunk/main/setup_native/source/packinfo/packinfo_office.txt All the gid_Module_Root_Extension_Dictionary_LANG are package descriptions for extension dictionaries, see http://svn.apache.org/viewvc/incubator/ooo/trunk/main/setup_native/source/packinfo/packinfo_office.txt?revision=1300105view=markup#l515 If you are still planning to package for Fedora, you will have to workaround this (extensions should be in its own package) and the problem of the duplication when the extensions is copied in the user installation (Fedora used a patched version of unopkg that added the link option). Regards -- Ariel Constenla-Haile La Plata, Argentina pgp55qO9HsVNI.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/27/13 2:48 AM, Ariel Constenla-Haile wrote: On Tue, Mar 26, 2013 at 11:03:09AM +0100, Andre Fischer wrote: IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I disagree and I don't see why this change should be a good thing. Being an extension has several advantages: [...] I am not sure what your point is. I'm not into making my point, nor having the last word; I already explained why I think these extensions are no extension at all, and why shipping them as pre-registered extensions is a bad idea; so I'm not going to start arguing, at the end I think my approach is good, you'll think it's not, and this won't change. As you repeated several times that you don't get what my point is, and I think I was already clear in this mail and the one to Hagar, I summarize, may be you get it clear: These are no extension at all (this meaning that their conception and realization goes against the notion of an extension that allows developer to extend OpenOffice without having to learn any single line of source code, nor modify the source code, nor build it), because: - an extension that requires the extension developer to modify the source code is not truly an extension - an extension that requires to get the whole source tree and set up the build environment in order to compile the OXT is not truly an extension The right approach, IMO, would have been at least to make these extensions buildable with the SDK only, at the time of being developed the SRB and the MySQL/OOoConn I pointed this out on the dba mailing list (in particular for C++ extensions, this has the advantage that if linked against older URE libraries, for a particular OOo version is needed, you only need to keep a copy of OO and the SDK, not a whole source tree) That's what I called a non-sense from the beginning. My other main opinion is that pre-registered extensions are bad, and applies to the following as well: - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. No. If the licenses where different then we would still need a way to make the set of included dictionaries configurable. We might end up using pre-bundled extensions for that. If otherwise dictionaries would be integrated into some module, then we would have to build the whole office for each language set (a matter of hours) instead of just building the installation set (just some minutes). I was talking about the way Sun/Oracle did it. Not as pre-registered or bundled extensions, but as packages by their own. I only know about Linux: the dictionaries were in their own rpm/deb package and you could choose whether to install it or not (may be on Windows this translated to select a custom installation, and un/marking the dictionary to be installed). From a Linux user perspective, this is a regression, and you are forced to install both the dictionaries and the pre-regs with the basis core-01 package. And as for pre-registered extensions and unopkg sync being bad, sorry for the fallacy of appealing to an authority, but I'm not insane to think I know more than Stephan: http://lists.freedesktop.org/archives/libreoffice/2012-August/036627.html - Forces the developer to write clean code that does not use anything outside the ODK. You must be kidding, nothing outside the ODK is not what happened with the Presenter Screen, you know this as you were the one that developed it :) No, I am not kidding. If I look at the makefile of the presenter console I see this for linked libraries: SHL1STDLIBS=$(CPPUHELPERLIB)\ $(CPPULIB) \ $(SALLIB) The work-arounds used to develop the Present Screen only show how badly designed is sometimes the API (I'm talking about the canvas module, a *whole* API module that cannot be used by the API users). IMO this is the proof that this was no clean code that uses only stuff in ODK: http://www.openoffice.org/api/docs/common/ref/com/sun/star/drawing/XPresenterHelper.html Again. I don't see your point. See above, an extension should not require the extension developer to study any single line of core code, not modifying it, in order to achieve the goal of the extension. This interface is a collection of functions that are necessary to implement larger parts of the presenter screen as extension. The methods of this interface give access to services that can, at the moment, only implemented in the Office core, not in an extension. And it goes on like this:
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote: Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't have any problem at all. I don't think that it will help us if we react this way. I am not reacting. Please don't turn this into a circus like the one with the 0^0. Really nobody wanted that you revert anything here. I am no native English speaker, but for the content, and the tone, of Andre mails, I understood he wanted his extension back: I don't see why this change should be a good thing. I was hoping that I would find the time in the future to fix this Including the pre-bundled extensions into the core is a workaround not a fix. We are still able (well until your changes) to release the presenter console under Apache license I still don' t see the benefit of the change. [...] This is something that I have used several times in the past and always was very glad that I had it. And he got it back (together with the Presentation Minimizer, as it makes no sense to have one pre-registered extension and the other integrated). Again, I don't have any problem at all, nor then, nor now :) Regards -- Ariel Constenla-Haile La Plata, Argentina pgpKqmt4rcVeV.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 27 March 2013 15:23, Ariel Constenla-Haile arie...@apache.org wrote: On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote: Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't have any problem at all. I don't think that it will help us if we react this way. I am not reacting. Please don't turn this into a circus like the one with the 0^0. Really nobody wanted that you revert anything here. I am no native English speaker, but for the content, and the tone, of Andre mails, I understood he wanted his extension back: For the record, you are not the only one who understood that it should be reverted. I think we need to a bit more careful on this list, not to demotivate people doing a fine job. rgds Jan I. I don't see why this change should be a good thing. I was hoping that I would find the time in the future to fix this Including the pre-bundled extensions into the core is a workaround not a fix. We are still able (well until your changes) to release the presenter console under Apache license I still don' t see the benefit of the change. [...] This is something that I have used several times in the past and always was very glad that I had it. And he got it back (together with the Presentation Minimizer, as it makes no sense to have one pre-registered extension and the other integrated). Again, I don't have any problem at all, nor then, nor now :) Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/27/13 3:23 PM, Ariel Constenla-Haile wrote: On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote: Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't have any problem at all. I glad to hear that, anything would have surprised me a little bit ;-9 I don't think that it will help us if we react this way. I am not reacting. Please don't turn this into a circus like the one with the 0^0. sorry if I used the wrong words, I simply didn't understand why you reverted it. And please no 0^0 circus ;-) Really nobody wanted that you revert anything here. I am no native English speaker, but for the content, and the tone, of Andre mails, I understood he wanted his extension back: I think it is simply a misunderstanding. Let me try to explain it. 1. you workaround an issue with pre-registered extensions by converting and integrating the extension into the normal code. The integration of these extensions in the normal code is a good thing from my point of view because I see it as well as a very useful core feature. Another option would have been to fix the pre-registered extension issue. You decided to solve the problem by working on the integration. Good so far. 2. Andre tried to explain that the design of for example the presenter screen is focused of being an extension. Otherwise the design would have been completely different and he would have used core feature directly and different. And he saw no real benefit for the user and I believe he wasn't aware of the linux issue with pre-registered extensions, at least not in detail. Maybe he used the wrong words (we are all no native speakers) but I believe he didn't wanted to revert it at any point. I am sure Andre will comment it as well. I don't see why this change should be a good thing. I was hoping that I would find the time in the future to fix this Including the pre-bundled extensions into the core is a workaround not a fix. We are still able (well until your changes) to release the presenter console under Apache license I still don' t see the benefit of the change. [...] This is something that I have used several times in the past and always was very glad that I had it. And he got it back (together with the Presentation Minimizer, as it makes no sense to have one pre-registered extension and the other integrated). +1 Again, I don't have any problem at all, nor then, nor now :) ok good, can we revert it then because I don't see that anybody has the time to dive deeper in the extension manager. At least when Andre confirmed that he didn't wanted revert anything. Juergen Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 27.03.2013 15:23, Ariel Constenla-Haile wrote: Please don't turn this into a circus like the one with the 0^0. In this we agree :-) While I still stand by my arguments, I see now that I should have chosen different words. I have the highest respect for you and your work and did not intend to attack you. Please accept my apologies. As an explanation: I have spend considerable time on the development of the presenter console. I guess I would have just liked to have been informed before the changes where made. Regarding the revert: Please revert the revert. Yes, I am convinced that extensions are a good thing and the concept should be used more often, but I think the primary reason four your change is a pragmatic one: fix installation problems on Linux that pose a real problem for our users, not handle an internal design question that no user knows about or cares for. It is a workaround but it is a necessary workaround. And certainly better than no fix at all. And most importantly, as this is an Apache project, you are the one who is willing to invest time and energy. I am just the guy who is complaining. Therefore it is you, who has the right to make the decision. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Didn't read all the replies, but anyway: +1. Also good for startup-performance, if I remember correctly... On 22.03.2013 17:15, Jürgen Schmidt wrote: Hi, the so called 3layer office is not really useful anymore (it was never) and makes more problems than it helps. I thought that AOO 4.0 would be the best time to start at least with the necessary rework. The main idea is to use a new simplified directory layout and tweak the necessary config file (*rc, *.ini), rpath or similar linker flags where necessary etc. Eliminate the URE completely because we don't really want support it as a standalone product. I did some initial work so far and I am now able to build an office for Windows, MacOS and Linux with a new simplified directory layout. Windows and MacOS have already one main directory whereas on Linux we have openoffice (basis layer + URE) and openoffice4 (brand layer). I removed all this base-link, ure-link, URE, urelib stuff and reorganized the directories. Example layout on Linux: openoffice4 openoffice4/help openoffice4/presets openoffice4/program - contains basis-link/program + URE/bin + URE/lib openoffice4/program/misc - former URE/share/misc - will be removed openoffice4/README openoffice4/README.html openoffice4/readmes openoffice4/share In general the layout becomes more equal on all platforms. The good news is that the office work on all 3 platforms, I am able to select Java, extensions seems to work as well. Python is not yet tested, language packs are not yet tested and built but in general I am thinking it will be no problem. Advantage of this move would be a simplified structure, long term a simplified configuration when the *rc/*.ini files are consolidated. Easier deployment on Linux, no conflicts with an URE from LO or the distro at all. My idea is to continue this basic work, do further cleanup in the office as well as the build system, do further testing including the SDK... Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? On demand I can provide test builds if there are people interested to help with testing. Juergen - 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: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Fri, Mar 22, 2013 at 12:15 PM, Jürgen Schmidt jogischm...@gmail.comwrote: On demand I can provide test builds if there are people interested to help with testing. Juergen Great work. May I suggest you upload such test builds to some cloud drive (GDrive, dropbox, etc) and share the url to the list? TIA! FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/25/13 5:22 PM, Ariel Constenla-Haile wrote: On Mon, Mar 25, 2013 at 12:58:17PM -0300, Ariel Constenla-Haile wrote: I gave a new built trunk version a try on my MacBook and the presenter screen doesn't work. AOO 3.4.1 worked. It works on Windows and Linux, where I could test. Did you check if the libraries were even delivered from the module? This should copy the libraries: http://svn.apache.org/viewvc/openoffice/trunk/main/sdext/prj/d.lst?revision=1457159view=markup ..\%__SRC%\lib\*.dylib %_DEST%\lib%_EXT%\*.dylib Or even installed? http://svn.apache.org/viewvc/openoffice/trunk/main/scp2/source/ooo/file_library_ooo.scp?revision=1457159view=markup#l1340 UNXSUFFIX is .dylib, so this look fine. If delivered, and installed, see if the components can be instantiated: Sub Test Dim oPresenterJob as Object Dim oPresenterProtocol as Object Dim oMinimizer as Object Dim oMinimizerDlg as Object oPresenterJob= CreateUnoService(com.sun.star.comp.Draw.framework.PresenterScreenJob) oPresenterProtocol= CreateUnoService(vnd.sun.star.sdext.presenter.PresenterProtocolHandler) oMinimizer= CreateUnoService(com.sun.star.comp.ui.dialogs.PresentationMinimizerDialog) oMinimizerDlg = CreateUnoService(com.sun.star.comp.PPPOptimizerImp) End Sub Now that I look at this, even if there is no profile migration, I should change the names to avoid name clashes. I did a quick check and the macro worked, all services could be instantiated. I removed the user profile and ow it works which is of course good. I thought I had started with a clean user profile yesterday already. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/25/13 6:37 PM, Ariel Constenla-Haile wrote: On Mon, Mar 25, 2013 at 05:37:06PM +0100, Andre Fischer wrote: On 25.03.2013 03:36, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I don't want to discuss the reason for the design as extension here because it coming from the past and personally think extensions are good fro many things but not for everything. What I would have preferred is at least a short proposal mail in front of the change that you plan to do that. I disagree and I don't see why this change should be a good thing. Being an extension has several advantages: - Updates can be provided independently of the AOO release cycle. When was the Presenter Screen released since OpenOffice is at the ASF? This is something that I have used several times in the past and always was very glad that I had it. Did AOO ever release the extensions? No. You can go to the extension site and there are still the Sun/Oracle versions of these extensions (the wiki publisher is even named Sun). - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. - Forces the developer to write clean code that does not use anything outside the ODK. You must be kidding, nothing outside the ODK is not what happened with the Presenter Screen, you know this as you were the one that developed it :) The work-arounds used to develop the Present Screen only show how badly designed is sometimes the API (I'm talking about the canvas module, a *whole* API module that cannot be used by the API users). IMO this is the proof that this was no clean code that uses only stuff in ODK: http://www.openoffice.org/api/docs/common/ref/com/sun/star/drawing/XPresenterHelper.html This interface is a collection of functions that are necessary to implement larger parts of the presenter screen as extension. The methods of this interface give access to services that can, at the moment, only implemented in the Office core, not in an extension. Could you have developed the Presenter Screen without such a workaround? The same applies for the ReportBuilder, but we don't build it anyway. A normal extension developer could have never developed the Presenter Screen. The Presenter Screen and the Report Builder needed code in the application core (and not only designing new API): for the case of the Presenter Screen, could it work without the code here? http://svn.apache.org/viewvc/openoffice/trunk/main/sd/source/ui/presenter/ I think this doesn't matter here and the design is of course related to the general decision to provide it as extension. From my pov it is a very useful core feature and integrated in the code directly make sense. The question is if the design at all would have been completely different without the tweaks and workarounds? So you choose the worst example, the WikiPublisher and the Presentation Minimizer are certainly pure UNO code, but the PS no. I personally would like to see more code moved to extensions than the other way round. While I agree in general, I disagree with the case of these three extensions. I tend to agree but the ReportBuilder is a different problem. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. No, I guess the user can deactivate the UNO component (I'm kidding). How does the user deactivate it now? As bundled extension is not listed in the Extension Manager. The average user will have no idea that the Presenter Screen is installed as an extension. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 25.03.2013 18:37, Ariel Constenla-Haile wrote: On Mon, Mar 25, 2013 at 05:37:06PM +0100, Andre Fischer wrote: On 25.03.2013 03:36, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I disagree and I don't see why this change should be a good thing. Being an extension has several advantages: - Updates can be provided independently of the AOO release cycle. When was the Presenter Screen released since OpenOffice is at the ASF? This is something that I have used several times in the past and always was very glad that I had it. Did AOO ever release the extensions? No. You can go to the extension site and there are still the Sun/Oracle versions of these extensions (the wiki publisher is even named Sun). I am not sure what your point is. I said that in the past I have gladly used the opportunity to release bug fixes for the presenter console without having to wait for the next release of OpenOffice.org. I do not claim that this is the preferred way. The presenter console extensions has not been released under AOO because it was part of AOO and there where not improvements or bug fixes that needed out of sync distribution. And I did not find the time to put a new version with updated license into the extension repository. - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. No. If the licenses where different then we would still need a way to make the set of included dictionaries configurable. We might end up using pre-bundled extensions for that. If otherwise dictionaries would be integrated into some module, then we would have to build the whole office for each language set (a matter of hours) instead of just building the installation set (just some minutes). - Forces the developer to write clean code that does not use anything outside the ODK. You must be kidding, nothing outside the ODK is not what happened with the Presenter Screen, you know this as you were the one that developed it :) No, I am not kidding. If I look at the makefile of the presenter console I see this for linked libraries: SHL1STDLIBS=$(CPPUHELPERLIB)\ $(CPPULIB)\ $(SALLIB) The work-arounds used to develop the Present Screen only show how badly designed is sometimes the API (I'm talking about the canvas module, a *whole* API module that cannot be used by the API users). IMO this is the proof that this was no clean code that uses only stuff in ODK: http://www.openoffice.org/api/docs/common/ref/com/sun/star/drawing/XPresenterHelper.html Again. I don't see your point. Is the UNO API perfectly or at least well designed? No, certainly not. But it is a lot better designed than the underlying core libraries. Yes, I needed a small set of functions that where not present via the API. So what? It was not available in the core either. This interface is a collection of functions that are necessary to implement larger parts of the presenter screen as extension. The methods of this interface give access to services that can, at the moment, only implemented in the Office core, not in an extension. And it goes on like this: With time some, maybe all, methods can moved to other, better suited, interfaces. I admit that I was too lazy to do that and clean up the UNO API a bit more. Could you have developed the Presenter Screen without such a workaround? The same applies for the ReportBuilder, but we don't build it anyway. A normal extension developer could have never developed the Presenter Screen. And again, what is your point? The presenter console makes heavy use of the canvas. The canvas is used for every graphical output, for every pixel on the screen. And every call to the canvas is made via the UNO API. Of course you finally implement missing functionality on top of the core libraries. But that is abstracted
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Tue, Mar 26, 2013 at 10:32:58AM +0100, Jürgen Schmidt wrote: You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I don't want to discuss the reason for the design as extension here because it coming from the past and personally think extensions are good fro many things but not for everything. What I would have preferred is at least a short proposal mail in front of the change that you plan to do that. Mea culpa, it didn't ever cross my mind to do so, nor thought the change was controversial, I just opened the bug reports on March the 9th https://issues.apache.org/ooo/show_bug.cgi?id=121871 https://issues.apache.org/ooo/show_bug.cgi?id=121872 https://issues.apache.org/ooo/show_bug.cgi?id=121873 submitted the patch, and in the weekend committed the code (which I tested on two platforms for two weeks). I would expect that people/developers are subscribed to our issues mailing list, and read the bug reports (at least, I do so). If for every code commit you expect a mail (and possible -IMO- pointless discussion here on the mailing list with people that know nothing about code - what at the ends is just of waste of developer time reading the mails and answering), then it would be better to implement code review, like LO has done with gerrit. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. No, I guess the user can deactivate the UNO component (I'm kidding). How does the user deactivate it now? As bundled extension is not listed in the Extension Manager. The average user will have no idea that the Presenter Screen is installed as an extension. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. I don't see a regression here, from the user perspective, in 3.4.1 the Presenter Screen cannot be deactivated. The missing option to disable the presenter screen is a valid point from Andre. As I answered to Hagar, an option in the Options dialog, and the respective configuration registry entry is the best approach, and very doable. Note that I am not a lunatic who wants to have always the reason and the last word, nor a drama queen who will leave to LO because someone didn't like a commit of mine; on the contrary, if Andre does not like the approach, I'm fine with him reverting it :) But please, if doing so, then * fix the preregister extension/uno sync brokenness on Linux * and/or fix the original bug with the deadlock which ended on the extension being prereg. * and make sure that in time, for the release, the extensions are ready to be released, too * fixing the problem of the double space consumption by preregistered extensions would also be fine, thought it does not seem simple All of these problems are not present with my approach of integrating these two extensions (I guess this is the reason why it never crossed my mind that this change would be something polemic/arguable). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpV6gF_ONdyF.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/26/13 11:07 AM, Ariel Constenla-Haile wrote: On Tue, Mar 26, 2013 at 10:32:58AM +0100, Jürgen Schmidt wrote: You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I don't want to discuss the reason for the design as extension here because it coming from the past and personally think extensions are good fro many things but not for everything. What I would have preferred is at least a short proposal mail in front of the change that you plan to do that. Mea culpa, it didn't ever cross my mind to do so, nor thought the change was controversial, I just opened the bug reports on March the 9th https://issues.apache.org/ooo/show_bug.cgi?id=121871 https://issues.apache.org/ooo/show_bug.cgi?id=121872 https://issues.apache.org/ooo/show_bug.cgi?id=121873 submitted the patch, and in the weekend committed the code (which I tested on two platforms for two weeks). I would expect that people/developers are subscribed to our issues mailing list, and read the bug reports (at least, I do so). me to but I miss a lot of messages as well, I read so many emails ;-) If for every code commit you expect a mail (and possible -IMO- pointless discussion here on the mailing list with people that know nothing about code - what at the ends is just of waste of developer time reading the mails and answering), then it would be better to implement code review, like LO has done with gerrit. I don't think we need to discuss everything but a short mail should be also no big effort. In most cases where deeper knowledge is required I expect less discussion or feedback. The advantage is that nobody can complain later about the change ;-) I don't think it is a problem. I am working now for IBM today and some people seems to have a problem with IBM as one of the bigger sponsors in this project. We want collaborate with others and don't want control anything. We just want to drive things forward where we can. And I personally started to inform early about potential bigger changes to ensure that people know about it and can't complain later. We did it for the sidebar and involve the community early and collect feedback. That's it. I think the gerrit approach is also very interesting but don't know enough about it at the moment. I am not sure if would really help us at the moment. Or something similar. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. No, I guess the user can deactivate the UNO component (I'm kidding). How does the user deactivate it now? As bundled extension is not listed in the Extension Manager. The average user will have no idea that the Presenter Screen is installed as an extension. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. I don't see a regression here, from the user perspective, in 3.4.1 the Presenter Screen cannot be deactivated. The missing option to disable the presenter screen is a valid point from Andre. As I answered to Hagar, an option in the Options dialog, and the respective configuration registry entry is the best approach, and very doable. Note that I am not a lunatic who wants to have always the reason and the last word, nor a drama queen who will leave to LO because someone didn't like a commit of mine; on the contrary, if Andre does not like the approach, I'm fine with him reverting it :) I don't think this will is necessary, all here are very happy with your work in the project. And the change is not bad at all. But please, if doing so, then * fix the preregister extension/uno sync brokenness on Linux * and/or fix the original bug with the deadlock which ended on the extension being prereg. * and make sure that in time, for the release, the extensions are ready to be released, too * fixing the problem of the double space consumption by preregistered extensions would also be fine, thought it does not seem simple fixing or reworking, both would be fine in general. I haven't looked in the changes from Stephan in detail but every simplification is welcome. In this area the design was also driven by some questionable decision of others ;-) All of these problems are not present with my approach of integrating these two extensions (I guess this is the reason why it never crossed my mind that this change would be something polemic/arguable). one reason to keep them but the issues remain if we decide to bundle a further useful extension
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 26 March 2013 11:36, Jürgen Schmidt jogischm...@gmail.com wrote: On 3/26/13 11:07 AM, Ariel Constenla-Haile wrote: On Tue, Mar 26, 2013 at 10:32:58AM +0100, Jürgen Schmidt wrote: You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I don't want to discuss the reason for the design as extension here because it coming from the past and personally think extensions are good fro many things but not for everything. What I would have preferred is at least a short proposal mail in front of the change that you plan to do that. Mea culpa, it didn't ever cross my mind to do so, nor thought the change was controversial, I just opened the bug reports on March the 9th https://issues.apache.org/ooo/show_bug.cgi?id=121871 https://issues.apache.org/ooo/show_bug.cgi?id=121872 https://issues.apache.org/ooo/show_bug.cgi?id=121873 submitted the patch, and in the weekend committed the code (which I tested on two platforms for two weeks). I would expect that people/developers are subscribed to our issues mailing list, and read the bug reports (at least, I do so). me to but I miss a lot of messages as well, I read so many emails ;-) If for every code commit you expect a mail (and possible -IMO- pointless discussion here on the mailing list with people that know nothing about code - what at the ends is just of waste of developer time reading the mails and answering), then it would be better to implement code review, like LO has done with gerrit. I don't think we need to discuss everything but a short mail should be also no big effort. In most cases where deeper knowledge is required I expect less discussion or feedback. The advantage is that nobody can complain later about the change ;-) I don't think it is a problem. I am working now for IBM today and some people seems to have a problem with IBM as one of the bigger sponsors in this project. We want collaborate with others and don't want control anything. We just want to drive things forward where we can. And I personally started to inform early about potential bigger changes to ensure that people know about it and can't complain later. We did it for the sidebar and involve the community early and collect feedback. That's it. I think the gerrit approach is also very interesting but don't know enough about it at the moment. I am not sure if would really help us at the moment. Or something similar. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. No, I guess the user can deactivate the UNO component (I'm kidding). How does the user deactivate it now? As bundled extension is not listed in the Extension Manager. The average user will have no idea that the Presenter Screen is installed as an extension. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. I don't see a regression here, from the user perspective, in 3.4.1 the Presenter Screen cannot be deactivated. The missing option to disable the presenter screen is a valid point from Andre. As I answered to Hagar, an option in the Options dialog, and the respective configuration registry entry is the best approach, and very doable. Note that I am not a lunatic who wants to have always the reason and the last word, nor a drama queen who will leave to LO because someone didn't like a commit of mine; on the contrary, if Andre does not like the approach, I'm fine with him reverting it :) I don't think this will is necessary, all here are very happy with your work in the project. And the change is not bad at all. But please, if doing so, then * fix the preregister extension/uno sync brokenness on Linux * and/or fix the original bug with the deadlock which ended on the extension being prereg. * and make sure that in time, for the release, the extensions are ready to be released, too * fixing the problem of the double space consumption by preregistered extensions would also be fine, thought it does not seem simple fixing or reworking, both would be fine in general. I haven't looked in the changes from Stephan in detail but every simplification is welcome. In this area the design was also driven by some questionable decision of others ;-) All of these problems are not present with my approach of integrating these two extensions (I guess this is the reason why it never crossed my mind that this
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Ariel Constenla-Haile wrote: If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. In the case of dictionaries (which is anyway marginal with respect to the current discussion) I actually find that what OpenOffice is doing now, i.e., bundling them as extensions, is a good solution. Development of dictionaries, especially those for spell checking, has nothing to do with OpenOffice development, dictionaries are reused across multiple projects and have a variety of licenses and contributors. So even if all dictionaries were available under ALv2 (purely theoretical of course!) I would still see benefits in bundling them as extensions. I don't recall seeing many community members against packaging dictionaries as extensions: for end-users this was surely a big improvements over the previous manual installation. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 3/25/13 3:36 AM, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I gave a new built trunk version a try on my MacBook and the presenter screen doesn't work. AOO 3.4.1 worked. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Mon, Mar 25, 2013 at 04:29:16PM +0100, Jürgen Schmidt wrote: On 3/25/13 3:36 AM, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I gave a new built trunk version a try on my MacBook and the presenter screen doesn't work. AOO 3.4.1 worked. It works on Windows and Linux, where I could test. Did you check if the libraries were even delivered from the module? This should copy the libraries: http://svn.apache.org/viewvc/openoffice/trunk/main/sdext/prj/d.lst?revision=1457159view=markup ..\%__SRC%\lib\*.dylib %_DEST%\lib%_EXT%\*.dylib Or even installed? http://svn.apache.org/viewvc/openoffice/trunk/main/scp2/source/ooo/file_library_ooo.scp?revision=1457159view=markup#l1340 UNXSUFFIX is .dylib, so this look fine. For anything else, I can't help, I don't build on Mac. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpKeuyBwOSrF.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Mon, Mar 25, 2013 at 12:58:17PM -0300, Ariel Constenla-Haile wrote: I gave a new built trunk version a try on my MacBook and the presenter screen doesn't work. AOO 3.4.1 worked. It works on Windows and Linux, where I could test. Did you check if the libraries were even delivered from the module? This should copy the libraries: http://svn.apache.org/viewvc/openoffice/trunk/main/sdext/prj/d.lst?revision=1457159view=markup ..\%__SRC%\lib\*.dylib %_DEST%\lib%_EXT%\*.dylib Or even installed? http://svn.apache.org/viewvc/openoffice/trunk/main/scp2/source/ooo/file_library_ooo.scp?revision=1457159view=markup#l1340 UNXSUFFIX is .dylib, so this look fine. If delivered, and installed, see if the components can be instantiated: Sub Test Dim oPresenterJob as Object Dim oPresenterProtocol as Object Dim oMinimizer as Object Dim oMinimizerDlg as Object oPresenterJob= CreateUnoService(com.sun.star.comp.Draw.framework.PresenterScreenJob) oPresenterProtocol= CreateUnoService(vnd.sun.star.sdext.presenter.PresenterProtocolHandler) oMinimizer= CreateUnoService(com.sun.star.comp.ui.dialogs.PresentationMinimizerDialog) oMinimizerDlg = CreateUnoService(com.sun.star.comp.PPPOptimizerImp) End Sub Now that I look at this, even if there is no profile migration, I should change the names to avoid name clashes. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpaNspfmhjS0.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 25.03.2013 03:36, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I disagree and I don't see why this change should be a good thing. Being an extension has several advantages: - Updates can be provided independently of the AOO release cycle. This is something that I have used several times in the past and always was very glad that I had it. - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. - Forces the developer to write clean code that does not use anything outside the ODK. I personally would like to see more code moved to extensions than the other way round. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. -Andre Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Mon, Mar 25, 2013 at 05:37:06PM +0100, Andre Fischer wrote: On 25.03.2013 03:36, Ariel Constenla-Haile wrote: On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). I disagree and I don't see why this change should be a good thing. Being an extension has several advantages: - Updates can be provided independently of the AOO release cycle. When was the Presenter Screen released since OpenOffice is at the ASF? This is something that I have used several times in the past and always was very glad that I had it. Did AOO ever release the extensions? No. You can go to the extension site and there are still the Sun/Oracle versions of these extensions (the wiki publisher is even named Sun). - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. If dictionaries were ALv2, for sure AOO would include them, as Sun/Oracle did (this was something the native-lang asked for long time). So this is something we use with dictionaries just because we cannot include them by default. - Forces the developer to write clean code that does not use anything outside the ODK. You must be kidding, nothing outside the ODK is not what happened with the Presenter Screen, you know this as you were the one that developed it :) The work-arounds used to develop the Present Screen only show how badly designed is sometimes the API (I'm talking about the canvas module, a *whole* API module that cannot be used by the API users). IMO this is the proof that this was no clean code that uses only stuff in ODK: http://www.openoffice.org/api/docs/common/ref/com/sun/star/drawing/XPresenterHelper.html This interface is a collection of functions that are necessary to implement larger parts of the presenter screen as extension. The methods of this interface give access to services that can, at the moment, only implemented in the Office core, not in an extension. Could you have developed the Presenter Screen without such a workaround? The same applies for the ReportBuilder, but we don't build it anyway. A normal extension developer could have never developed the Presenter Screen. The Presenter Screen and the Report Builder needed code in the application core (and not only designing new API): for the case of the Presenter Screen, could it work without the code here? http://svn.apache.org/viewvc/openoffice/trunk/main/sd/source/ui/presenter/ So you choose the worst example, the WikiPublisher and the Presentation Minimizer are certainly pure UNO code, but the PS no. I personally would like to see more code moved to extensions than the other way round. While I agree in general, I disagree with the case of these three extensions. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. No, I guess the user can deactivate the UNO component (I'm kidding). How does the user deactivate it now? As bundled extension is not listed in the Extension Manager. The average user will have no idea that the Presenter Screen is installed as an extension. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. I don't see a regression here, from the user perspective, in 3.4.1 the Presenter Screen cannot be deactivated. So I see the following advantages: * pre-bundled extensions are broken on Linux: https://issues.apache.org/ooo/show_bug.cgi?id=120606 Of course, the proper fix for this bug is fixing it. Why is the Presenter Screen a bundled extension? To work around https://issues.apache.org/ooo/show_bug.cgi?id=120338 Could the extension be a normal extension as downloaded from the extension site without deadlocking? This is just another point to have this integrated and not as an extension * we have three extensions that we never released. Why? I'm not sure. But for these three, the argument that having them
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Le 25/03/2013 17:37, Andre Fischer a écrit : - Easy control over the feature set that is shipped with OpenOffice. This is something that we use extensively for dictionaries. +1. I know about the dictionaries. But basically I think that we should keep the bundled dics as few as possible and let the user install extra dics if needed. In this special case I would like to know how the user can turn of the presenter screen. Did you add a button or option for this?. The original idea was that activation/deactivation is done by activating/installing or deactivating/uninstalling the extension. That was somewhat undermined by product managers who shipped the extension with OOo but hid the Presenter Console extension from the extension manager. It was still possible to uninstall the extension but not via the UI. +1. There are some advanced features that are of no use for me (like those related to Impress). In the past I could deactivate them (in 3.4.0 IIRC). But well, perhaps there is no real gain to remove the extension. There is a balance to find between a sleek code with extensions à la Firefox for advanced features and a more complex code with more features included with less hassle for the users who need them. Advanced features could be developed as extensions and integrated in the main code if they meet big success. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Mon, Mar 25, 2013 at 09:41:18PM +0100, Hagar Delest wrote: +1. There are some advanced features that are of no use for me (like those related to Impress). In the past I could deactivate them (in 3.4.0 IIRC). But well, perhaps there is no real gain to remove the extension. But you do hit the point for removing this extension that is no extension at all: you (average user) cannot deactivate in the UI. Being integrated in the Office is as simple as adding a checkbox on the Options dialog, and for system administrators an option in an xcu file. Besides, now as preregistered extensions, they consume space both in the installation folder and every user directory on your system. Integrated into the Office code is simply a library, configuration files are merged, and images part of the global images.zip. Besides, as preregistered extensions, they are broken on Linux. The fact that the Presenter Screen ended as a preregistered extensions is just a hack to workaround bugs, not to mention the whole buggy unopkg sync and preregistered extensions by itself (no wonder Stephan Bergmann removed them long ago http://lists.freedesktop.org/archives/libreoffice/2012-August/036627.html) Besides the fact that, although being linked only to URE libs, this is by no means a normal extension, and has deep dependencies in the core code that go beyond mere UNO services as could be used by other extensions; so the fact of this being an extension is no argument in favor of the code being easy to maintain, on the contrary, by looking at the history [ariel@localhost presenter]$ git log --oneline . 1b138b4 i121873 - Integrate the Presenter Screen 7f0e1cf #121388# - adapt renaming: Apache OpenOffice -- OpenOffice 77d41e6 i119977 - Update version number to 4.0.0 4edadde Fixed build breaker and some cleanup. 8c43b8f #i119206# use generic methods in presenter-console's makefile e35efbe fix extension maximal version dependency b9e592a extensions with updated license get a new version also update min-/max-dependency to Apache OpenOffice 3.4+ 5729e2e #i119168# update granted extensions to match their ALv2 license 9979154 Added AL2 license. c30c02e Update headers to Alv2 headers ffe7841 Update headers to Alv2 headers cbc6f46 remove svn:executable properties from more source files 50c3fa1 remove svn:executable properties from document templates and samples ff38d84 remove svn:executable properties from source files c5fe3be Update headers to Alv2 headers fbb9cd7 Update headers to Alv2 headers 1f83643 Update headers to Alv2 headers 539ae5f Update headers to Alv2 headers 1842c5f Update headers to Alv2 headers c946a2d Update headers to Alv2 headers 00639e4 Update headers to Alv2 headers 6b9fba5 Initial import of the old OOo hg repository tip revision. this shows the code hasn't been touched since it was transfered to the ASF, since 2011: changeset: 276848:2418cfd47c84 user:Andre Fischerandre.f.fisc...@oracle.com date:Wed Mar 23 09:42:08 2011 +0100 files: sdext/source/presenter/description.xml description: impress211: #i110990# Increased version number (micro) of presenter screen extension to 1.1.1. changeset: 276845:d8cdb29e0a59 user:Andre Fischerandre.f.fisc...@oracle.com date:Fri Mar 11 15:22:17 2011 +0100 files: sd/source/ui/dlg/present.cxx sd/source/ui/slideshow/slideshow.cxx sdext/source/presenter/PresenterScreen.cxx description: impress211: #i110990# Fixed remaining problems with display ids and indices. This could mean: a) the extension is bug-free and full-featured b) it is unmaintained Searching bugs in bugzilla, and looking at the logs in http://opengrok.libreoffice.org/xref/core/sdext/source/presenter/ seems to indicate that is far from (a). IMHO, in the case of this particular extension, having it integrated makes it more easy to debug and hack on, the problem (a serious one in this project) is to attract community contributors to work on it. Advanced features could be developed as extensions and integrated in the main code if they meet big success. This is far from reality. Advanced features need integration into the office code. With an hybrid extension that is no real extension because of it dependencies you end up with something difficult to maintain. The Report Builder and MySQL Connector are very good examples, besides the Presenter Screen. Just try to install the MySQL connector and connect to a socket (Unix) or a pipe (Windows); I could cite more examples, but I already wrote too much (besides, I used too much the word besides). Regards -- Ariel Constenla-Haile La Plata, Argentina pgp7yfjodgVyi.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Top posting. It was just my user POV. If there is more advantages to merge such code in the main trunk, according to your experience as developer, then I've no problem with that. I'm not a developer so I don't want to interfere with false good ideas... Hagar Le 25/03/2013 23:12, Ariel Constenla-Haile a écrit : On Mon, Mar 25, 2013 at 09:41:18PM +0100, Hagar Delest wrote: +1. There are some advanced features that are of no use for me (like those related to Impress). In the past I could deactivate them (in 3.4.0 IIRC). But well, perhaps there is no real gain to remove the extension. But you do hit the point for removing this extension that is no extension at all: you (average user) cannot deactivate in the UI. Being integrated in the Office is as simple as adding a checkbox on the Options dialog, and for system administrators an option in an xcu file. Besides, now as preregistered extensions, they consume space both in the installation folder and every user directory on your system. Integrated into the Office code is simply a library, configuration files are merged, and images part of the global images.zip. Besides, as preregistered extensions, they are broken on Linux. The fact that the Presenter Screen ended as a preregistered extensions is just a hack to workaround bugs, not to mention the whole buggy unopkg sync and preregistered extensions by itself (no wonder Stephan Bergmann removed them long ago http://lists.freedesktop.org/archives/libreoffice/2012-August/036627.html) Besides the fact that, although being linked only to URE libs, this is by no means a normal extension, and has deep dependencies in the core code that go beyond mere UNO services as could be used by other extensions; so the fact of this being an extension is no argument in favor of the code being easy to maintain, on the contrary, by looking at the history [ariel@localhost presenter]$ git log --oneline . 1b138b4 i121873 - Integrate the Presenter Screen 7f0e1cf #121388# - adapt renaming: Apache OpenOffice -- OpenOffice 77d41e6 i119977 - Update version number to 4.0.0 4edadde Fixed build breaker and some cleanup. 8c43b8f #i119206# use generic methods in presenter-console's makefile e35efbe fix extension maximal version dependency b9e592a extensions with updated license get a new version also update min-/max-dependency to Apache OpenOffice 3.4+ 5729e2e #i119168# update granted extensions to match their ALv2 license 9979154 Added AL2 license. c30c02e Update headers to Alv2 headers ffe7841 Update headers to Alv2 headers cbc6f46 remove svn:executable properties from more source files 50c3fa1 remove svn:executable properties from document templates and samples ff38d84 remove svn:executable properties from source files c5fe3be Update headers to Alv2 headers fbb9cd7 Update headers to Alv2 headers 1f83643 Update headers to Alv2 headers 539ae5f Update headers to Alv2 headers 1842c5f Update headers to Alv2 headers c946a2d Update headers to Alv2 headers 00639e4 Update headers to Alv2 headers 6b9fba5 Initial import of the old OOo hg repository tip revision. this shows the code hasn't been touched since it was transfered to the ASF, since 2011: changeset: 276848:2418cfd47c84 user:Andre Fischerandre.f.fisc...@oracle.com date:Wed Mar 23 09:42:08 2011 +0100 files: sdext/source/presenter/description.xml description: impress211: #i110990# Increased version number (micro) of presenter screen extension to 1.1.1. changeset: 276845:d8cdb29e0a59 user:Andre Fischerandre.f.fisc...@oracle.com date:Fri Mar 11 15:22:17 2011 +0100 files: sd/source/ui/dlg/present.cxx sd/source/ui/slideshow/slideshow.cxx sdext/source/presenter/PresenterScreen.cxx description: impress211: #i110990# Fixed remaining problems with display ids and indices. This could mean: a) the extension is bug-free and full-featured b) it is unmaintained Searching bugs in bugzilla, and looking at the logs in http://opengrok.libreoffice.org/xref/core/sdext/source/presenter/ seems to indicate that is far from (a). IMHO, in the case of this particular extension, having it integrated makes it more easy to debug and hack on, the problem (a serious one in this project) is to attract community contributors to work on it. Advanced features could be developed as extensions and integrated in the main code if they meet big success. This is far from reality. Advanced features need integration into the office code. With an hybrid extension that is no real extension because of it dependencies you end up with something difficult to maintain. The Report Builder and MySQL Connector are very good examples, besides the Presenter Screen. Just try to install the MySQL connector and connect to a socket (Unix) or a pipe (Windows); I could cite more examples, but I already wrote too much (besides, I used too much the word besides). Regards - To unsubscribe, e-mail:
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On 22/03/2013 Jürgen Schmidt wrote: Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? Good news! So this will also mean that we get rid of the following layout, right? /opt/openoffice-341/ |-- openoffice.org `-- openoffice.org3 and that the example layout you sent is the full OpenOffice directory layout. On demand I can provide test builds if there are people interested to help with testing. Sure. If you don't build it on a very recent system, I can test them on a variety of Linux-based systems (also using older glibc versions). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Am 03/22/2013 05:15 PM, schrieb Jürgen Schmidt: [...] Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? You are absolutely right with cleaning up the old 3-layer-office. A big +1 to get rid of it. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Le 24/03/2013 18:34, Rob Weir a écrit : What is the advantage to the user? I don't think users care about the directory structure. This is an internal implementation detail. So It doesn't change much for the user but it does bring more consistency for the GNU/Linux platform as said at the beginning of the topic. I've always found this additional openoffice.org folder in /opt rather confusing. And it can lead to problems if you want to run in parallel 2 versions of OO. So a big +1 for this change. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
There are two parts to the extensions for writing aids. I think there is some serious low-hanging fruit for improving how this works. MATERIAL INSTALLED IN THE PROGRAM SPACE. The last time I checked, some writing aids and extensions that are bundled and considered part of a distro are installed with the binaries (e.g., under the Program Files location on Windows). It matters whether those are installed as .oxt files or they are installed as folders (with the same names) that are the extracted files from the .oxt. With Apache OpenOffice 3.4.1 (en-US) installed on Microsoft Windows XP SP3 there are the following in an installation of mine: * dict-fr.oxt\ is a folder (6.3 MB on disk). It is stashed under C:\Program Files\OpenOffice.org 3\share\uno_ packages\IF2_tmp_\ (I'm not quite sure why I have it, but there it is.) * presentation-minimizer.oxt\ (2.2 MB), another folder, not the .oxt package. This is under ... share\prereg\bundled\ * presenter-screen.oxt\ (3.2 MB), another folder, same place as the preceding one * dict-en.oxt (6.2MB) an actual .oxt package, not one that has been unpacked. This is under ... share\extensions\install\ If this were extracted, it would occupy 24,788kB. In addition, it appears to have, in one package, a mix of aids for en_US, en_AU, en_CA, en_GB, and en_ZA. An .oxt is a Zip package with a structure that preceded what is done with ODF packages. (There is significant advantage to moving to an ODF-package form.) MATERIAL INSTALLED IN USER SPACE This is in a place where applications can put data (such as profiles) that is dynamic and is not locked-down the same as the material in the Program Space. Here is what is there in the same configuration as the above. These are all under C:\Documents and Settings\orcmid\Application Data\ OpenOffice.org\3\user\uno_packages\cache\uno_packages\ a folder occupying 91.3MB on Disk. There are six subdirectory directories each containing another directory which is an expanded .oxt. These expanded .oxt folders are: * dict-en-au-2008-12-15.oxt\ (21.4MB on disk) * dict-en-nz-2008-12-03.oxt\ (21.3MB) * dict-en.oxt\ (24.2 MB) * en_CA_2_0_0.oxt\ (21.4MB) * en_US.oxt\ (704 kB!) * presentation-minimizer.oxt\ (2.17 MB) I can understand .oxt *files* being part of the installed set in the Program Files area. I don't understand why all caching is not in the Application Data space, but I also wonder whether keeping more data inside of the .oxt package might also be productive. I think the point is that there are some odd dependencies and redundancies here. I don't profess to understand them. I am only observing their presence in the code and user profile footprints. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Sunday, March 24, 2013 10:35 To: dev@openoffice.apache.org Subject: Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1 [ ... ] The one directory structure issue that we do get complaints about is our placement of dictionaries. We've heard from admins some concern about the size of our per-user profile, with the argument that immutable files like dictionaries should not be in the profile. For example, one admin was managing a training lab where he needed to reset the profiles for each training machine via a script. He did this by copying from a master profile over the network. But each profile directory was something like 40MB, due to inclusion of the dictionaries. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Am Sonntag, 24. März 2013 um 21:59 schrieb Dennis E. Hamilton: There are two parts to the extensions for writing aids. I think there is some serious low-hanging fruit for improving how this works. MATERIAL INSTALLED IN THE PROGRAM SPACE. The last time I checked, some writing aids and extensions that are bundled and considered part of a distro are installed with the binaries (e.g., under the Program Files location on Windows). It matters whether those are installed as .oxt files or they are installed as folders (with the same names) that are the extracted files from the .oxt. With Apache OpenOffice 3.4.1 (en-US) installed on Microsoft Windows XP SP3 there are the following in an installation of mine: * dict-fr.oxt\ is a folder (6.3 MB on disk). It is stashed under C:\Program Files\OpenOffice.org 3\share\uno_ packages\IF2_tmp_\ (I'm not quite sure why I have it, but there it is.) * presentation-minimizer.oxt\ (2.2 MB), another folder, not the .oxt package. This is under ... share\prereg\bundled\ * presenter-screen.oxt\ (3.2 MB), another folder, same place as the preceding one * dict-en.oxt (6.2MB) an actual .oxt package, not one that has been unpacked. This is under ... share\extensions\install\ If this were extracted, it would occupy 24,788kB. In addition, it appears to have, in one package, a mix of aids for en_US, en_AU, en_CA, en_GB, and en_ZA. An .oxt is a Zip package with a structure that preceded what is done with ODF packages. (There is significant advantage to moving to an ODF-package form.) MATERIAL INSTALLED IN USER SPACE This is in a place where applications can put data (such as profiles) that is dynamic and is not locked-down the same as the material in the Program Space. Here is what is there in the same configuration as the above. These are all under C:\Documents and Settings\orcmid\Application Data\ OpenOffice.org\3\user\uno_packages\cache\uno_packages\ a folder occupying 91.3MB on Disk. There are six subdirectory directories each containing another directory which is an expanded .oxt. These expanded .oxt folders are: * dict-en-au-2008-12-15.oxt\ (21.4MB on disk) * dict-en-nz-2008-12-03.oxt\ (21.3MB) * dict-en.oxt\ (24.2 MB) * en_CA_2_0_0.oxt\ (21.4MB) * en_US.oxt\ (704 kB!) * presentation-minimizer.oxt\ (2.17 MB) I can understand .oxt *files* being part of the installed set in the Program Files area. I don't understand why all caching is not in the Application Data space, but I also wonder whether keeping more data inside of the .oxt package might also be productive. I think the point is that there are some odd dependencies and redundancies here. I don't profess to understand them. I am only observing their presence in the code and user profile footprints. observing is the trivial part here, we are aware of this far not optimal situation. The point is that we had to change pre-packaged extensions to bundled ones because of the license of dictionaries. And the whole extension management is of course very complex, too complex and fragile. We have definitely to do some redesign/ cleanup here. But as always the work has to be done Volunteers are welcome. Juergen - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Sunday, March 24, 2013 10:35 To: dev@openoffice.apache.org Subject: Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1 [ ... ] The one directory structure issue that we do get complaints about is our placement of dictionaries. We've heard from admins some concern about the size of our per-user profile, with the argument that immutable files like dictionaries should not be in the profile. For example, one admin was managing a training lab where he needed to reset the profiles for each training machine via a script. He did this by copying from a master profile over the network. But each profile directory was something like 40MB, due to inclusion of the dictionaries. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Sun, Mar 24, 2013 at 01:59:07PM -0700, Dennis E. Hamilton wrote: * presentation-minimizer.oxt\ (2.2 MB), another folder, not the .oxt package. This is under ... share\prereg\bundled\ * presenter-screen.oxt\ (3.2 MB), another folder, same place as the preceding one These two are now part of the normal installation, no longer extensions. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpA0KW1KEK6K.pgp Description: PGP signature
RE: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
@Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. - Dennis -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Sunday, March 24, 2013 16:27 To: dev@openoffice.apache.org Subject: Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1 On Sun, Mar 24, 2013 at 01:59:07PM -0700, Dennis E. Hamilton wrote: * presentation-minimizer.oxt\ (2.2 MB), another folder, not the .oxt package. This is under ... share\prereg\bundled\ * presenter-screen.oxt\ (3.2 MB), another folder, same place as the preceding one These two are now part of the normal installation, no longer extensions. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton wrote: @Ariel, This is where they are in 3.4.1. Are you talking about a change for 4.0 or something else? Yes, by now I meant right-now, on trunk (it would be helpful if people -reading this mailing list, not normal users- use the builds from the build bots; it would help finding bugs/regressions early, not one week before voting the release). The ones quoted below were installed with the normal installation (which is why they are under C:\Program Files\OpenOffice.org 3\). I did nothing to obtain them as extensions. You are right, these extensions were bundled with the installation; IMO it was a non-sense from the beginning to develop these as extensions (at least the presentation minimizer and the presenter screen, that have no external dependencies). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpQ82Ob82jTe.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Sun, Mar 24, 2013 at 01:34:52PM -0400, Rob Weir wrote: The one directory structure issue that we do get complaints about is our placement of dictionaries. We've heard from admins some concern about the size of our per-user profile, with the argument that immutable files like dictionaries should not be in the profile. There is an old set of configure switches that allows pointing to directories for the spelling/thesaurus/hyphenation dictionaries. It still works on Linux, where it is more useful: most free software use the same dictionaries, so Linux distributions configure them to share all the same dictionaries in a single, shared location: /usr/share/myspell/ /usr/share/mythes/ /usr/share/hyphen/ It might be useful to turn this into a runtime configuration option, instead of setting it at build-time; system administrators could change this with simple xcu configuration files. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpvwuPrcIFiI.pgp Description: PGP signature
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Fri, Mar 22, 2013 at 7:52 PM, Ian C i...@amham.net wrote: Hi Jürgen, On Sat, Mar 23, 2013 at 12:15 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, the so called 3layer office is not really useful anymore (it was never) and makes more problems than it helps. I thought that AOO 4.0 would be the best time to start at least with the necessary rework. The main idea is to use a new simplified directory layout and tweak the necessary config file (*rc, *.ini), rpath or similar linker flags where necessary etc. Eliminate the URE completely because we don't really want support it as a standalone product. I did some initial work so far and I am now able to build an office for Windows, MacOS and Linux with a new simplified directory layout. Windows and MacOS have already one main directory whereas on Linux we have openoffice (basis layer + URE) and openoffice4 (brand layer). I removed all this base-link, ure-link, URE, urelib stuff and reorganized the directories. Example layout on Linux: openoffice4 openoffice4/help openoffice4/presets openoffice4/program - contains basis-link/program + URE/bin + URE/lib openoffice4/program/misc - former URE/share/misc - will be removed openoffice4/README openoffice4/README.html openoffice4/readmes openoffice4/share In general the layout becomes more equal on all platforms. The good news is that the office work on all 3 platforms, I am able to select Java, extensions seems to work as well. Python is not yet tested, language packs are not yet tested and built but in general I am thinking it will be no problem. Advantage of this move would be a simplified structure, long term a simplified configuration when the *rc/*.ini files are consolidated. Easier deployment on Linux, no conflicts with an URE from LO or the distro at all. My idea is to continue this basic work, do further cleanup in the office as well as the build system, do further testing including the SDK... Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? On demand I can provide test builds if there are people interested to help with testing. is the code available on a branch? If so I can make some time to help check the build on Fedora and do some smoke testing. Or if you can get the code to me in some other way let me know. I have limited time but happy to try these things if that helps. Is there some reason this shouldn't just be ported to our main trunk? Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Cheers, Ian C - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK Achieving happiness requires the right combination of Zen and Zin.
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Sorry for top posting but: +1 !!! Groetjes, Olaf Am 22.03.2013 17:15, schrieb Jürgen Schmidt: Hi, the so called 3layer office is not really useful anymore (it was never) and makes more problems than it helps. I thought that AOO 4.0 would be the best time to start at least with the necessary rework. The main idea is to use a new simplified directory layout and tweak the necessary config file (*rc, *.ini), rpath or similar linker flags where necessary etc. Eliminate the URE completely because we don't really want support it as a standalone product. I did some initial work so far and I am now able to build an office for Windows, MacOS and Linux with a new simplified directory layout. Windows and MacOS have already one main directory whereas on Linux we have openoffice (basis layer + URE) and openoffice4 (brand layer). I removed all this base-link, ure-link, URE, urelib stuff and reorganized the directories. Example layout on Linux: openoffice4 openoffice4/help openoffice4/presets openoffice4/program - contains basis-link/program + URE/bin + URE/lib openoffice4/program/misc - former URE/share/misc - will be removed openoffice4/README openoffice4/README.html openoffice4/readmes openoffice4/share In general the layout becomes more equal on all platforms. The good news is that the office work on all 3 platforms, I am able to select Java, extensions seems to work as well. Python is not yet tested, language packs are not yet tested and built but in general I am thinking it will be no problem. Advantage of this move would be a simplified structure, long term a simplified configuration when the *rc/*.ini files are consolidated. Easier deployment on Linux, no conflicts with an URE from LO or the distro at all. My idea is to continue this basic work, do further cleanup in the office as well as the build system, do further testing including the SDK... Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? On demand I can provide test builds if there are people interested to help with testing. Juergen - 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: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
On Fri, Mar 22, 2013 at 9:15 AM, Jürgen Schmidt jogischm...@gmail.comwrote: Hi, the so called 3layer office is not really useful anymore (it was never) and makes more problems than it helps. I thought that AOO 4.0 would be the best time to start at least with the necessary rework. The main idea is to use a new simplified directory layout and tweak the necessary config file (*rc, *.ini), rpath or similar linker flags where necessary etc. Eliminate the URE completely because we don't really want support it as a standalone product. I did some initial work so far and I am now able to build an office for Windows, MacOS and Linux with a new simplified directory layout. Windows and MacOS have already one main directory whereas on Linux we have openoffice (basis layer + URE) and openoffice4 (brand layer). I removed all this base-link, ure-link, URE, urelib stuff and reorganized the directories. Example layout on Linux: openoffice4 openoffice4/help openoffice4/presets openoffice4/program - contains basis-link/program + URE/bin + URE/lib openoffice4/program/misc - former URE/share/misc - will be removed openoffice4/README openoffice4/README.html openoffice4/readmes openoffice4/share In general the layout becomes more equal on all platforms. The good news is that the office work on all 3 platforms, I am able to select Java, extensions seems to work as well. Python is not yet tested, language packs are not yet tested and built but in general I am thinking it will be no problem. Advantage of this move would be a simplified structure, long term a simplified configuration when the *rc/*.ini files are consolidated. Easier deployment on Linux, no conflicts with an URE from LO or the distro at all. My idea is to continue this basic work, do further cleanup in the office as well as the build system, do further testing including the SDK... Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? On demand I can provide test builds if there are people interested to help with testing. Juergen I must confess I know next to nothing about the current architectural structure of OpenOffice, so when you originally brought this up, I was lost. My feeling at this point is any move to simplify things will be a big help! So, I look forward to working with this new structure, and seeing what it brings to performance as well as development! Thank you for your insights and work! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK Achieving happiness requires the right combination of Zen and Zin.
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Great work Jürgen, I am impressed. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
This has win, win, win all over it! Does this allow 4.0 to co-exist with 3.4.1 or LO? Regards, Dave Sent from my iPhone On Mar 22, 2013, at 1:53 PM, Andrew Douglas Pitonyak and...@pitonyak.org wrote: Great work Jürgen, I am impressed. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php - 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: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Hi Jürgen, On Sat, Mar 23, 2013 at 12:15 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, the so called 3layer office is not really useful anymore (it was never) and makes more problems than it helps. I thought that AOO 4.0 would be the best time to start at least with the necessary rework. The main idea is to use a new simplified directory layout and tweak the necessary config file (*rc, *.ini), rpath or similar linker flags where necessary etc. Eliminate the URE completely because we don't really want support it as a standalone product. I did some initial work so far and I am now able to build an office for Windows, MacOS and Linux with a new simplified directory layout. Windows and MacOS have already one main directory whereas on Linux we have openoffice (basis layer + URE) and openoffice4 (brand layer). I removed all this base-link, ure-link, URE, urelib stuff and reorganized the directories. Example layout on Linux: openoffice4 openoffice4/help openoffice4/presets openoffice4/program - contains basis-link/program + URE/bin + URE/lib openoffice4/program/misc - former URE/share/misc - will be removed openoffice4/README openoffice4/README.html openoffice4/readmes openoffice4/share In general the layout becomes more equal on all platforms. The good news is that the office work on all 3 platforms, I am able to select Java, extensions seems to work as well. Python is not yet tested, language packs are not yet tested and built but in general I am thinking it will be no problem. Advantage of this move would be a simplified structure, long term a simplified configuration when the *rc/*.ini files are consolidated. Easier deployment on Linux, no conflicts with an URE from LO or the distro at all. My idea is to continue this basic work, do further cleanup in the office as well as the build system, do further testing including the SDK... Still some work to do but from my point of view a useful move forward to get rid of this complex and unnecessary 3layer stuff. What do you think? On demand I can provide test builds if there are people interested to help with testing. is the code available on a branch? If so I can make some time to help check the build on Fedora and do some smoke testing. Or if you can get the code to me in some other way let me know. I have limited time but happy to try these things if that helps. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Cheers, Ian C - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
