Age	Commit message (Collapse)	Author
2018-11-21	weld SwCondCollPage	Caolán McNamara
	and put back original SvTreeListBox a11y factory use Change-Id: I4ad8ce29d8fed6ec5d44e9a1d641919a89226b79 Reviewed-on: https://gerrit.libreoffice.org/63501 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-14	move fmtfield	Caolán McNamara
	Change-Id: Ic3f4388ea2ca92d9e97d4a9e066eea07c7de79e5 Reviewed-on: https://gerrit.libreoffice.org/63363 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-07	move SvTreeListBox to vcl	Caolán McNamara
	Change-Id: I04a146d3d8a428ac1678827dc883525c40240a44 Reviewed-on: https://gerrit.libreoffice.org/62787 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-03-11	Move (and rename) graphic stuff from svtools to vcl	Tomaž Vajngerl
	This is preparing to change how GraphicManager works where it won't base itself around GraphicObject anymore but Graphic. No functional or cosmetic change was made to the classes, only changes that were needed because of the move and rename. The only thing that wasn't moved is the GraphicRenderer as it is not needed in vcl for now (but makes sense to move it in the future to keep graphic stuff together). grfmgr was renamed to GraphicObject as the GraphicManager will be changed a lot and most likely moved out, so the name grfmgr won't make any sense anymore. All the UNO implementations were renamed with a prefix Uno and used the same name as the class name. This is made to be more specific which are the Uno objects (for example graphic.cxx contained the implementation of XGraphic, which is similar to graph.cxx contains Graphic). Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137 Reviewed-on: https://gerrit.libreoffice.org/51068 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2017-11-15	drop now unused ToolPanelOpt	Caolán McNamara
	Change-Id: I26c93567f58b7b459eedbad85b5f3bfe554c8557 Reviewed-on: https://gerrit.libreoffice.org/44769 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-09-22	Ditch now unused GraphicExportDialog, GraphicExportOptionsDialog	Eike Rathke
	That was a dead end anyway, trying to partly reimplement SvFilterOptionsDialog ExportDialog, instead of implementing the necessary bits to use that one which has everything. Change-Id: Icde7422f2c2d7e26c07dfe921a4abda41e222b09 Reviewed-on: https://gerrit.libreoffice.org/42503 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2017-07-21	migrate to boost::gettext	Caolán McNamara
	* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "\|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-04-21	gbuild: Remove MSVC 2013 legacy code	David Ostrovsky
	Uwinapi is discontinued. Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01 Reviewed-on: https://gerrit.libreoffice.org/23198 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2017-02-09	tdf#105672 framework managed menu button	Maxim Monastirsky
	This adds a menu button that can use a popup menu controller to manage its menu. It supports 2 cases: - Use any controller that is registered in Controller.xcu, by specifing its .uno command. - Manage an arbitrary popup menu with MenuBarManager (assuming its items have proper .uno commands in their MenuItemData::aCommandStr). It means that a menu that was defined in a .ui file, can be used inside that .ui file without any additional code. This commit uses the new control to fix some currently non-working buttons in Calc's Notebookbar (but there are more that can be fixed the same way). It's not clear how long we will continue to use buttons (instead of toolboxes) for the Notebookbar, but hopefully this control will be useful in other places too. Change-Id: Ie00cde7cd7e39948948960ca2eff76e9db837109 Reviewed-on: https://gerrit.libreoffice.org/34103 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2016-10-05	convert the last two lonely FixedInfos to FixedText	Caolán McNamara
	Change-Id: Ia6ed5f71931a6141efb3d5e5eb329149d6850342