summaryrefslogtreecommitdiff
path: root/sdext/Library_presenter.mk
AgeCommit message (Collapse)Author
2013-04-14make file names match library namesPeter Foley
Change-Id: Id9b7decbf2f3cfc89e76e7c86a801904375971be
2013-01-26gbuild: fix silly "expandtabs" in makefile VIM modelinesMichael Stahl
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
2012-12-02sdext: there is a severe shortage of boost dependencies hereMichael Stahl
Change-Id: Ide652d073edc3321995b787b01ea9c0bf1920827
2012-11-21Turn presenter screen from bundled extension to plain codeStephan Bergmann
The immediate trigger was 5e5c11c664f67ff9fd1120905b09a32bea3b2f6c "fdo#42070 Fix RTL support in presenter console" causing build failures on Mac OS X when linking the extension against vcl, but there should be more benefits of going from a bundled-anyway extension to plain code. (Not the least to get rid of the com.sun.star.drawing.XPresenterHelper hack.) To avoid unnecessary confusion between the newly plain code and any instance of the old extension still installed (per-user or shared), I renamed all relevant identifiers as follows: * UNO implementation com.sun.star.comp.Draw.framework.PresenterScreenJob -> org.libreoffice.comp.PresenterScreenJob * UNO implementation com.sun.star.sdext.presenter.PresenterProtocolHandler -> org.libreoffice.comp.PresenterScreenProtocolHandler * protocol handler schema vnd.com.sun.star.comp.PresenterScreen -> vnd.org.libreoffice.presenterscreen * configuration schema /org.openoffice.Office.extension.PresenterScreen -> /org.openoffice.Office.PresenterScreen (it appears this contains little to no user-changeable data anyway, so not migrating it to a new user profile due to the schema name change should not be problematic) * job ID onDocumentOpenedJob -> org.libreoffice.PresenterScreen Even with these precautions, having the presenter screen installed both as plain code and as a (per-user or shared) extension still leads to a crash when activating presentation mode (likely due to how both codes want to take control of the screen). To mitigate this, existing installations of the extension are explicitly not migrated to new user profiles. The sdext/source/presenter/bitmaps/*.png files were moved to icon-themes/galaxy/sd/res/presenterscreen-*.png and are now accessed via SdResId (adding the relevant data to sd/source/ui/inc/res_bmp.hrc and sd/source/ui/app/res_bmp.src; not sure whether these locations are already ideal). The code itself has been left mostly unchanged in sdext/source/presenter/, and it still clumsily communicates with sd core code via XPresenterHelper. There is a lot of room for improvement here. The help data is left untouched at sdext/source/presenter/help/ and needs to be incorporated properly into helpcontent2 in a follow-up commit. The --disable-ext-presenter-console configure switch is gone. Change-Id: I71adb7ae6dcdbd1802151fce6e3871d8a2026332
2012-11-20fdo#42070-Fix RTL support in presenter consoleFaisal M. Al-Otaibi
Problems that still exist: 1-Help layout. 2-Slide sorter view (slides alignment). 3-Note view buttons. 4-Scroll bars. Change-Id: Ie78519358d2f6d847692ee870ecdc1790c5244e6 Reviewed-on: https://gerrit.libreoffice.org/1053 Tested-by: Lior Kaplan <kaplanlior@gmail.com> Reviewed-by: Andras Timar <atimar@suse.com> Tested-by: Andras Timar <atimar@suse.com>
2012-10-01fdo#50163 move definition of PLATFORMID into configure.inAndras Timar
Change-Id: Iea8385aa9213ccde7e6650cb934361597d508250
2012-07-02targetted improvement of UNO API includes / usageMichael Meeks
2012-06-11fdo#50964 - fix presenter console artwork locationMichael Meeks
Change-Id: I6c550bace0f085630116c86fa19fd0562a10951f
2012-04-19convert presenter console to passive registrationDavid Tardon
2012-04-14unusedcode: PresenterAnimation and PresenterAnimatorMatúš Kukan
2012-04-08gbuild: "use" vs. "add":Michael Stahl
Naming convention for gbuild methods: - "add" is used for stuff that is logically a part of the target (i.e. not registered at the Module, but defined in the target's makefile) - "use" is used for stuff that is logically a different target (i.e. it is registered at the Module, has it's own makefile, may be in a different module than the target)
2012-03-06gbuildize sdextDavid Tardon