Why is it so hard to make a Java program appear native?
An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Why is it so hard to make a Java program appear native?
On 11 August 2014 09:59, Peter Kelly kelly...@gmail.com wrote: An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? If you look at especially module svl, you will see how we use a meta language to define the UI items. We can change what the UI language generates pretty easy, and it is also pretty easy to change the layout itself. However the semantic, the editing is buried deep in the process model of AOO, there are no clear seperation between functionality and representation, as you would do in a modern program. rgds jan I. -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.co pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: About debugging tokenizer of writerfilter
On 09.08.2014 03:10, Hung Mark wrote: Hi, I tried to understand why my document doesn't format correctly. I followed steps on wiki : https://wiki.openoffice.org/wiki/WriterFilter ./uno -l libwriterfilter.so -c debugservices.ooxml.ScannerTestService -- file:///home/mark/num.docx error: libwriterfilter.so: cannot get factory of demanded implementation: debugservices.ooxml.ScannerTestService dying... ./uno -l libwriterfilter.so -c debugservices.doctok.ScannerTestService -- file:///home/mark/num.doc error: libwriterfilter.so: cannot get factory of demanded implementation: debugservices.doctok.ScannerTestService dying... Is the document outdated or did I miss anything? Yes to the first part of your question, maybe to the second :-) The wiki page describes a state during the development of the OOXML writer filter. I am not sure that it was updated to keep track with development. I was not directly involved in it so I can not give you any details. But I did look into it a couple of months ago to asses whether to build on it for a better OOXML support or whether to rewrite it. There are some interesting ideas in it but not all where realized and some don't work anymore. Maybe the dumping of tokens is a case of not working anymore. Some info that might help you: The source of the ooxml/ScannerTestService can found in main/writerfilter/unocomponent/debugservices/ooxml/OOXMLTestService.cxx There are some #ifdefs that depend on a DEBUG_ELEMENT environment variable. I don't know if that is important but I also don't see a place where it is ever defined. You might run the uno command in you debugger and place a breakpoint in ScannerTestService::run(). If you don't reach it then your problem is located in the UNO framework, otherwise it is in the OOXML scanner itself. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
On 11/08/14 09:59, Peter Kelly wrote: An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). indeed and as far as I know it was always a big challenge to make it working on all supported platforms. Well I am no expert in this area but we have the VCL layer (visual class library) with an API used all over in the code and certain backends wrapping the API to native calls (where necessary) on the different platforms. Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? The answer is probably yes but the effort is of course very high. The reason is that it is not so clearly separated as it should be. VCL is used deeply in the writer core as far as I know. For the support of mobile I believe a much better separation would be necessary to have the core independent of the UI or at least have the UI part accessed via a clean API that the UI part can be easier exchanged. Probably others can give more details Juergen -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com mailto:pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
On 11.08.2014 09:59, Peter Kelly wrote: An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ I know that the answer to this is not really important, but just in case. This gives you not 100% native rendering but maybe 80%: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but grown because of convenience or laziness. So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad). Maybe we need an experiment to see what is possible? Regards, Andre -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com mailto:pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
[RELEASE]: propose RC2 on revision 1616946
Hi, I would like to propose RC2 based on revision 1616946 from the AOO410 branch. The build is ongoing and I expect to have the builds available tomorrow or on Wednesday. Further details later ... Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[MWiki] Account creation
Greetings, I'd like an account to be created for me: * e-mail address: waav_zoungla-o...@yahoo.fr * account name: Amenel Thank you.
Re: [MWiki] Account creation
On 11/08/2014 Amenel VOGLOZIN wrote: I'd like an account to be created for me: * e-mail address: waav_zoungla-o...@yahoo.fr * account name: Amenel Account created. You will get a temporary password in a personal mail. Andrea - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Impress/ presentation - arrange graphics - send to back
Dear People from the OpenOffice developer community, I need help with programming a script for OpenOffice Impress. My script alread has the below features * save presentation document * read values from text boxes which are placed on slide 'Control' * according the the above values a specified directory is searched for images * corresponding to the number of images that were found .. + slide 2 (index 1) is copied and pasted ... OR .. + last slide/ slide with highest index is deleted * save presentation document * presentation is exported as PDF document and stored in a specified directory Unfortunately I didn't find a way to send the images to back. If this feature would be executed using the mouse the procedure would be: * right click image * context menu will be displayed * select below item from context menu .. Arrange Send To Back Thank you in advance, Peter --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ongoing OOXML development and implementation defined items.
Hi. Thanks to a (once again) good tip from andre, I found out why I could not see the OOXML sources and control the code. Be carefull when you upgrade svn client to newest, I had to do a fallback before svn up would work correctly. rgds jan I. On 4 August 2014 21:49, jan i j...@apache.org wrote: On 4 August 2014 18:23, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Jan asks good questions below. I have a comment with regard to (3) Will the OOXML implementation allow round-trip of our documents without loss of information? It strikes me that there are OOXML import and export capabilities already in Apache OpenOffice and a better question may have to do with whether those capabilities will satisfy condition (3) and how can they be improved to do so. I am assuming that Jan is considering more than AOO round-tripping with itself, although it would be strange were that not already true. The trick is round-tripping with other implementations of OOXML, perhaps, including the OOXML support of the AOO cousin, LibreOffice? Sadly enough round-trip within AOO is not at all given, but you are right I was thinking about the AOO specialities in e.g. Microsoft word (it could also be that the new development simply ignores these fields) I note that the current support is not being mentioned in this discussion so far. I think it may be that is related to the focus on implementations for mobile devices and other non-desktop solutions. It's not clear though. Or because the import function for OOXML does not work for a large amount of documents. thanks for clarifying my questions: rgds Jan I. -- Dennis E. Hamilton dennis.hamil...@acm.org+1-206-779-9430 https://keybase.io/orcmid PGP F96E 89FF D456 628A X.509 certs used and requested for signed e-mail -Original Message- From: jan i [mailto:j...@apache.org] Sent: Monday, August 4, 2014 08:42 To: dev Subject: Ongoing OOXML development and implementation defined items. Hi. Based on the information from dennis/peter, I think it would be highly interesting to know: 1) How are the implementation defined items implemented, is the intention to forward a list to dev@ and ask for opinions (of course in a style so an opinion is possible to give) ? 2) How will the implementation defined items, be documented, they are likely to change over time, to its problaly a poing where maintenance is needed, and thus a higher demand on documentation ? 3) Will the OOXML implementation allow round-trip of our documents without loss of information ? unlike the sidebar development, this develoment seems closed, I expect there are good reasons for it, but items where many can have an opinion (format conversion being a typical example) would be nice to discuss. thanks in advance. rgds jan I - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building OpenOffice on illumos with gcc
On 08/06/2014 12:09 AM, Alexander Pyhalov wrote: This is indeed the recommended way to contribute code. Apostolos, who did the initial work, already stated in this thread that we are allowed to use his work under the Apache license (the OpenOffice license terms), so there are no other concerns. Alexander, thanks a lot for your work, and if you provide some basic information for an entry in http://www.openoffice.org/porting/ we can surely add it to that page. Even better, we can gradually integrate your work so that it's not even a port any longer! Please make sure to tag issues appropriately, like prepending their title with [ILLUMOS], so that we can easily see the global picture while integrating them. Hello. I've reported most annoying issues here: https://issues.apache.org/ooo/show_bug.cgi?id=125361 https://issues.apache.org/ooo/show_bug.cgi?id=125362 https://issues.apache.org/ooo/show_bug.cgi?id=125363 https://issues.apache.org/ooo/show_bug.cgi?id=125364 https://issues.apache.org/ooo/show_bug.cgi?id=125365 https://issues.apache.org/ooo/show_bug.cgi?id=125366 https://issues.apache.org/ooo/show_bug.cgi?id=125368 https://issues.apache.org/ooo/show_bug.cgi?id=125369 https://issues.apache.org/ooo/show_bug.cgi?id=125370 https://issues.apache.org/ooo/show_bug.cgi?id=125371 https://issues.apache.org/ooo/show_bug.cgi?id=125372 https://issues.apache.org/ooo/show_bug.cgi?id=125373 I think that https://issues.apache.org/ooo/show_bug.cgi?id=125362 can be used as a covering issue. Also, note that I haven't tried to preserve Solaris/C52 port while doing this work, so some additional work is needed to allow Solaris/C52 and Solaris/GCC ports to coexist. Thanks for documenting your patches this way. Hopefully, some of our other Solaris developers will see this and test these out as well. And, maybe some of them have some ideas about co-existing with Solaris Studio, etc. -- - MzK For evil to flourish, it only requires good men to do nothing. -- Simon Wiesenthal - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
On 11 Aug 2014, at 3:42 pm, Andre Fischer awf@gmail.com wrote: Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but grown because of convenience or laziness. So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad). Maybe we need an experiment to see what is possible? I'll have a look into the code to understand the architecture better and then hopefully be able to contribute some more informed thoughts about it. From what you've described, it sounds like there is a dependence from the OO codebase to VCL, is that correct? If my initial understanding it is correct, it sounds like it would be possible to port this to iOS/Android with sufficient effort, though I think that writing a from-scratch UI would be needed, as you suggested. That is, largely to address the much smaller screen real estate and touch controls, and the types of UI layouts that are common on phones/tablets. The fact that OO can run in headless mode sounds promising, since the ability to access much of the functionality without any UI implies that a totally different UI could be put in place on top of this. -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Why is it so hard to make a Java program appear native?
On 11 August 2014 20:12, Peter Kelly kelly...@gmail.com wrote: On 11 Aug 2014, at 3:42 pm, Andre Fischer awf@gmail.com wrote: Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but grown because of convenience or laziness. So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad). Maybe we need an experiment to see what is possible? I'll have a look into the code to understand the architecture better and then hopefully be able to contribute some more informed thoughts about it. From what you've described, it sounds like there is a dependence from the OO codebase to VCL, is that correct? If my initial understanding it is correct, it sounds like it would be possible to port this to iOS/Android with sufficient effort, though I think that writing a from-scratch UI would be needed, as you suggested. That is, largely to address the much smaller screen real estate and touch controls, and the types of UI layouts that are common on phones/tablets. The fact that OO can run in headless mode sounds promising, since the ability to access much of the functionality without any UI implies that a totally different UI could be put in place on top of this. I just wonder if the effort pays off. AOO contains tons of very good ideas (proven over time) but equally old code. Juergen have multiple times argued that it might be more efficient, to pick the ideas and write new code with modern tools, i tend to agree to that. Please remember AOO is a good mixture of C/C++/Java/Python/Perl (I might have missed something), whereas a new codebase would be simpler. We might be able to avoid the big bang, by using AOO in headless mode and change to new code part by part. But I agree with andre that an experiment, just moving a little part would be a nice proof. just my 2ct. rgds jan I. -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Why is it so hard to make a Java program appear native?
On 11 Aug 2014, at 3:14 pm, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/08/14 09:59, Peter Kelly wrote: An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). indeed and as far as I know it was always a big challenge to make it working on all supported platforms. Well I am no expert in this area but we have the VCL layer (visual class library) with an API used all over in the code and certain backends wrapping the API to native calls (where necessary) on the different platforms. I think there's two aspects to this. One is the APIs for drawing things - bitmaps, shapes, text, etc. and the other is the APIs for working with widges. When I ported XeTeX to iOS I had to do the former; the old code used some APIs (AAT, Apple Advanced Typography) that are now deprecated on OS X and completely absent from iOS. On both platforms (which are much the same), this is CoreGraphics, CoreImage, and CoreText. The widget side of things is a more complex issue to address. Looking at the GSL/VCL description at https://www.openoffice.org/gsl/, there's APIs for things like a file picker, which up to and including iOS 7 aren't present on the platform; though thankfully this is introduced in iOS 8. For the support of mobile I believe a much better separation would be necessary to have the core independent of the UI or at least have the UI part accessed via a clean API that the UI part can be easier exchanged. I think it would be useful to have a clear separation between the drawing APIs and the widgets. Basically I see it as a stack, where you have the following (higher-numbered layers depending on lower-numbered). 4. Application-specific UI 3. Widget toolkit 2. Editing rendering code 1. Drawing APIs To maximise portability, it would be useful to take just layers 1 and 2, and then be able to use whatever widget toolkit is appropriate for the platform (typically, the native one). So on iOS for example, layer 1 is covered by the three libraries I mentioned above, and layer 3 is provided by UIKit (aka Cocoa Touch). Significantly, the layer 1 libraries are (almost) identical across iOS and OS X, and are exposed purely via C. Layer 3 differs between the two; OS X has an API called AppKit (aka Cocoa) in place of UIKit/Cocoa Touch. So with VCL, would an Apple-like separation of 1 and 3 be possible? -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Impress/ presentation - arrange graphics - send to back
Hi Peter, Peter Stölzgen schrieb: Dear People from the OpenOffice developer community, I need help with programming a script for OpenOffice Impress. My script alread has the below features * save presentation document * read values from text boxes which are placed on slide 'Control' * according the the above values a specified directory is searched for images I don't know yet whether the layer Control has the same properties in Impress than in Draw. But in Draw the shapes on the layer Control are always on top of the shapes from the other layers. * corresponding to the number of images that were found .. + slide 2 (index 1) is copied and pasted ... OR .. + last slide/ slide with highest index is deleted * save presentation document * presentation is exported as PDF document and stored in a specified directory Unfortunately I didn't find a way to send the images to back. If this feature would be executed using the mouse the procedure would be: * right click image * context menu will be displayed * select below item from context menu .. Arrange Send To Back The arrangement effects the property ZOrder. The shape with ZOrder=0 is drawn first and therefor at the back, but still in layer layout. You can manipulate the ZOrder, see https://wiki.openoffice.org/wiki/Documentation/DevGuide/Drawings/Ordering The draw page supports the service ShapeCollection, which gives you access to the shapes. But I'm not sure, whether Send To Back is what you really want. Send to Back makes only sense, if there are several shapes overlapping each other. Perhaps you want to set a shape to a background layer? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
