Spell-checking broken on first build
Dear all, I can't get the automatic spell-checking to work after doing a fresh git clone / build on (Arch) Linux. My autogen.sh is simply: --without-java --without-help The UI lets me set the text to English (which was the default) but when I go to Tools-Spelling, there are no language choices (only "None") in that dropdown. Any tips? Thanks! -Keith -- Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: vcl/source
vcl/source/window/toolbox2.cxx |2 -- 1 file changed, 2 deletions(-) New commits: commit 758d2099ae281e270ef014711b693580ab27206b Author: Keith Curtis <keit...@gmail.com> Date: Tue May 22 03:35:37 2018 -0400 Remove unnecessary code from ae37972cd25117d467d34ee8591c21dcbb5a0fec Git commit: ae37972cd25117d467d34ee8591c21dcbb5a0fec added some logic at the bottom to call Toolbox::SetItemImage to trigger the bitmap doubling code. This is no longer needed and is faster without. Change-Id: I0fb0538000d5616cb8d8a0ae35e15fb09cdf2c59 Reviewed-on: https://gerrit.libreoffice.org/54654 Tested-by: Jenkins <c...@libreoffice.org> Reviewed-by: Thorsten Behrens <thorsten.behr...@cib.de> diff --git a/vcl/source/window/toolbox2.cxx b/vcl/source/window/toolbox2.cxx index de0faecfa607..cc86b0d9a0f9 100644 --- a/vcl/source/window/toolbox2.cxx +++ b/vcl/source/window/toolbox2.cxx @@ -373,7 +373,6 @@ void ToolBox::InsertItem( sal_uInt16 nItemId, const Image& rImage, ToolBoxItemBi // create item and add to list mpData->m_aItems.insert( (nPos < mpData->m_aItems.size()) ? mpData->m_aItems.begin()+nPos : mpData->m_aItems.end(), ImplToolItem( nItemId, rImage, nBits ) ); -SetItemImage(nItemId, rImage); mpData->ImplClearLayoutData(); ImplInvalidate( true ); @@ -393,7 +392,6 @@ void ToolBox::InsertItem( sal_uInt16 nItemId, const Image& rImage, const OUStrin // create item and add to list mpData->m_aItems.insert( (nPos < mpData->m_aItems.size()) ? mpData->m_aItems.begin()+nPos : mpData->m_aItems.end(), ImplToolItem( nItemId, rImage, MnemonicGenerator::EraseAllMnemonicChars(rText), nBits ) ); -SetItemImage(nItemId, rImage); mpData->ImplClearLayoutData(); ImplInvalidate( true ); ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: RFC: using system font size instead of querying HiDPI stuff
Hi Noel, I think it would be quite reasonable to change the code to also enable the HiDPI behavior if the system font is a certain size. I support your change of direction, but the current code works quite well by detecting DPI from the OS / DE and so I would only override that logic it the scalefactor was 1 and the system font was large. The relevant routine is CountDPIScaleFactor(): http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#834 Another way to go about it would be to force the screen DPI to be 192 (ignoring what the OS tells us). I'm not entirely sure of the difference in behavior between those two scenarios. On my machine, the DPI is 192 and the scale factor is 2 and everything is therefore consistent. Another way to go about it would be to add a UI option to manually override the scale factor and / or screen DPI. Good luck! -Keith -- View this message in context: http://nabble.documentfoundation.org/RFC-using-system-font-size-instead-of-querying-HiDPI-stuff-tp4137065p4137973.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: Changes to 'refs/changes/66/8166/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/66/8166/3'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/66/8166/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/43/8743/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/49/8749/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/49/8749/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/68/8168/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/37/8637/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/37/8637/4'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/37/8637/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/68/8168/3'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/68/8168/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/61/7261/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/61/7261/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/19/8519/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/19/8519/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-2' - vcl/source
vcl/source/window/toolbox.cxx |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit e9451c72d4e221c993e1af30652c62a538d033d8 Author: Keith Curtis keit...@gmail.com Date: Mon Mar 17 20:16:57 2014 -0400 Hopefully fix Windows HiDPI toolbar layout bug On Windows HiDPI, toolbar buttons are cut off. This may fix the problem. Here is a screenshot: http://i.imgur.com/NADAvYi.png I can't prove this fixes anything on Windows because I can't see this on Linux and don't really understand the surrounding code. On the other hand, it is easy to prove this is reasonable code. Change-Id: I69c19ad46844bead942ce63883d163cb9d0690c9 Reviewed-on: https://gerrit.libreoffice.org/8637 Tested-by: LibreOffice gerrit bot ger...@libreoffice.org Reviewed-by: Caolán McNamara caol...@redhat.com Tested-by: Caolán McNamara caol...@redhat.com (cherry picked from commit 509441038ab95dd3a60efd1b6c302bf22bfbc631) Reviewed-on: https://gerrit.libreoffice.org/8743 Reviewed-by: Keith Curtis keit...@gmail.com Reviewed-by: Miklos Vajna vmik...@collabora.co.uk Tested-by: Miklos Vajna vmik...@collabora.co.uk diff --git a/vcl/source/window/toolbox.cxx b/vcl/source/window/toolbox.cxx index 0d7bf8a..4613879 100644 --- a/vcl/source/window/toolbox.cxx +++ b/vcl/source/window/toolbox.cxx @@ -1747,8 +1747,8 @@ sal_Bool ToolBox::ImplCalcItem() longnDropDownArrowWidth = TB_DROPDOWNARROWWIDTH; // set defaults if image or text is needed but empty -nDefWidth = GetDefaultImageSize().Width(); -nDefHeight = GetDefaultImageSize().Height(); +nDefWidth = GetDefaultImageSize().Width() * GetDPIScaleFactor(); +nDefHeight = GetDefaultImageSize().Height() * GetDPIScaleFactor(); mnWinHeight = 0; // determine minimum size necessary in NWF ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-2-3' - vcl/source
vcl/source/window/toolbox.cxx |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit b740953537b324e157b22ce3bd46611b01f78e47 Author: Keith Curtis keit...@gmail.com Date: Mon Mar 17 20:16:57 2014 -0400 Hopefully fix Windows HiDPI toolbar layout bug On Windows HiDPI, toolbar buttons are cut off. This may fix the problem. Here is a screenshot: http://i.imgur.com/NADAvYi.png I can't prove this fixes anything on Windows because I can't see this on Linux and don't really understand the surrounding code. On the other hand, it is easy to prove this is reasonable code. Change-Id: I69c19ad46844bead942ce63883d163cb9d0690c9 Reviewed-on: https://gerrit.libreoffice.org/8637 Tested-by: LibreOffice gerrit bot ger...@libreoffice.org Reviewed-by: Caolán McNamara caol...@redhat.com Tested-by: Caolán McNamara caol...@redhat.com (cherry picked from commit 509441038ab95dd3a60efd1b6c302bf22bfbc631) Reviewed-on: https://gerrit.libreoffice.org/8749 Reviewed-by: Keith Curtis keit...@gmail.com Reviewed-by: Miklos Vajna vmik...@collabora.co.uk Tested-by: Norbert Thiebaud nthieb...@gmail.com Reviewed-by: Norbert Thiebaud nthieb...@gmail.com diff --git a/vcl/source/window/toolbox.cxx b/vcl/source/window/toolbox.cxx index 0d7bf8a..4613879 100644 --- a/vcl/source/window/toolbox.cxx +++ b/vcl/source/window/toolbox.cxx @@ -1747,8 +1747,8 @@ sal_Bool ToolBox::ImplCalcItem() longnDropDownArrowWidth = TB_DROPDOWNARROWWIDTH; // set defaults if image or text is needed but empty -nDefWidth = GetDefaultImageSize().Width(); -nDefHeight = GetDefaultImageSize().Height(); +nDefWidth = GetDefaultImageSize().Width() * GetDPIScaleFactor(); +nDefHeight = GetDefaultImageSize().Height() * GetDPIScaleFactor(); mnWinHeight = 0; // determine minimum size necessary in NWF ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/source
vcl/source/window/toolbox.cxx |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit 509441038ab95dd3a60efd1b6c302bf22bfbc631 Author: Keith Curtis keit...@gmail.com Date: Mon Mar 17 20:16:57 2014 -0400 Hopefully fix Windows HiDPI toolbar layout bug On Windows HiDPI, toolbar buttons are cut off. This may fix the problem. Here is a screenshot: http://i.imgur.com/NADAvYi.png I can't prove this fixes anything on Windows because I can't see this on Linux and don't really understand the surrounding code. On the other hand, it is easy to prove this is reasonable code. Change-Id: I69c19ad46844bead942ce63883d163cb9d0690c9 Reviewed-on: https://gerrit.libreoffice.org/8637 Tested-by: LibreOffice gerrit bot ger...@libreoffice.org Reviewed-by: Caolán McNamara caol...@redhat.com Tested-by: Caolán McNamara caol...@redhat.com diff --git a/vcl/source/window/toolbox.cxx b/vcl/source/window/toolbox.cxx index 3cb7322..61204c9 100644 --- a/vcl/source/window/toolbox.cxx +++ b/vcl/source/window/toolbox.cxx @@ -1736,8 +1736,8 @@ bool ToolBox::ImplCalcItem() longnDropDownArrowWidth = TB_DROPDOWNARROWWIDTH; // set defaults if image or text is needed but empty -nDefWidth = GetDefaultImageSize().Width(); -nDefHeight = GetDefaultImageSize().Height(); +nDefWidth = GetDefaultImageSize().Width() * GetDPIScaleFactor(); +nDefHeight = GetDefaultImageSize().Height() * GetDPIScaleFactor(); mnWinHeight = 0; // determine minimum size necessary in NWF ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-2' - sc/source sd/source sfx2/source svx/source sw/source vcl/source
sc/source/ui/miscdlgs/autofmt.cxx|2 -
sc/source/ui/sidebar/CellAppearancePropertyPanel.src |1
sd/source/ui/sidebar/MasterPagesSelector.cxx |4 ++
sfx2/source/dialog/dinfdlg.cxx | 11 +-
sfx2/source/sidebar/DeckLayouter.cxx |8 ++--
sfx2/source/sidebar/SidebarChildWindow.cxx |2 -
sfx2/source/sidebar/SidebarController.cxx| 32 ++-
sfx2/source/sidebar/TabBar.cxx | 25 --
svx/source/sidebar/tools/ValueSetWithTextControl.cxx | 29 +
svx/source/tbxctrls/fontworkgallery.cxx |4 ++
svx/source/tbxctrls/tbcontrl.cxx | 13 +++
sw/source/ui/table/tautofmt.cxx |2 -
vcl/source/window/toolbox2.cxx |2 +
13 files changed, 109 insertions(+), 26 deletions(-)
New commits:
commit dfffb3244a4fd8cd58fa7786cbec626604dc61e1
Author: Keith Curtis keit...@gmail.com
Date: Thu Jan 2 16:01:07 2014 -0500
hidpi: Sidebar, fontwork, autoformat and other improvements.
This is a second batch of HiDPI changes. It fixes the following areas:
Sidebar
* Impress Master pages preview
* deck title height
* tab (icon) bar
* valueset dropdown control
* wider maximum width
* Draw and other misc. buttons which didn't get fixed by earlier
change to Toolbar.SetItemImage
There are several more sidebar issues, but it is much improved.
Other changes
* Writer and Calc auto-format dialog text
* file-properties document image
* fontwork gallery preview size
* Calc table border control
Change-Id: I95a0169a3b011836b1c75b3dcacb2733c9567ef3
Reviewed-on: https://gerrit.libreoffice.org/8519
Reviewed-by: Norbert Thiebaud nthieb...@gmail.com
Tested-by: Norbert Thiebaud nthieb...@gmail.com
diff --git a/sc/source/ui/miscdlgs/autofmt.cxx
b/sc/source/ui/miscdlgs/autofmt.cxx
index 425014f..a536b22 100644
--- a/sc/source/ui/miscdlgs/autofmt.cxx
+++ b/sc/source/ui/miscdlgs/autofmt.cxx
@@ -109,7 +109,7 @@ void ScAutoFmtPreview::MakeFonts( sal_uInt16 nIndex, Font
rFont, Font rCJKFont
if ( pCurData )
{
rFont = rCJKFont = rCTLFont = GetFont();
-Size aFontSize( rFont.GetSize().Width(), 10 );
+Size aFontSize( rFont.GetSize().Width(), 10 * GetDPIScaleFactor() );
const SvxFontItem*pFontItem = (const SvxFontItem*)
pCurData-GetItem( nIndex, ATTR_FONT );
const SvxWeightItem* pWeightItem = (const SvxWeightItem*)
pCurData-GetItem( nIndex, ATTR_FONT_WEIGHT );
diff --git a/sc/source/ui/sidebar/CellAppearancePropertyPanel.src
b/sc/source/ui/sidebar/CellAppearancePropertyPanel.src
index 0087628..4542e4c 100644
--- a/sc/source/ui/sidebar/CellAppearancePropertyPanel.src
+++ b/sc/source/ui/sidebar/CellAppearancePropertyPanel.src
@@ -167,6 +167,7 @@ Control RID_POPUPPANEL_APPEARANCE_CELL_BORDERSTYLE
DialogControl = TRUE;
Border = FALSE;
+//This is broken with the auto-doubled hidpi bitmaps
Size = MAP_PIXEL( POPUPPANEL_MARGIN_SMALL_PIXEL * 2 + 108,
POPUPPANEL_MARGIN_SMALL_PIXEL * 2 + 138);
ToolBox TB_BORDER1
diff --git a/sd/source/ui/sidebar/MasterPagesSelector.cxx
b/sd/source/ui/sidebar/MasterPagesSelector.cxx
index 783d4ed..9d1444a 100644
--- a/sd/source/ui/sidebar/MasterPagesSelector.cxx
+++ b/sd/source/ui/sidebar/MasterPagesSelector.cxx
@@ -87,6 +87,10 @@ MasterPagesSelector::MasterPagesSelector (
PreviewValueSet::SetRightMouseClickHandler (
LINK(this, MasterPagesSelector, RightClickHandler));
PreviewValueSet::SetStyle(PreviewValueSet::GetStyle() |
WB_NO_DIRECTSELECT);
+
+if ( GetDPIScaleFactor() 1 )
+mpContainer-SetPreviewSize(MasterPageContainer::LARGE);
+
PreviewValueSet::SetPreviewSize(mpContainer-GetPreviewSizePixel());
PreviewValueSet::Show();
diff --git a/sfx2/source/dialog/dinfdlg.cxx b/sfx2/source/dialog/dinfdlg.cxx
index c603adc..4975c61 100644
--- a/sfx2/source/dialog/dinfdlg.cxx
+++ b/sfx2/source/dialog/dinfdlg.cxx
@@ -1055,7 +1055,16 @@ void SfxDocumentPage::Reset( const SfxItemSet rSet )
aURL.SetSmartProtocol( INET_PROT_FILE );
aURL.SetSmartURL( aFactory);
const OUString rMainURL = aURL.GetMainURL( INetURLObject::NO_DECODE );
-m_pBmp-SetImage( SvFileInformationManager::GetImage( aURL, sal_True ) );
+Image aImage = SvFileInformationManager::GetImage( aURL, sal_True );
+
+if ( GetDPIScaleFactor() 1)
+{
+BitmapEx b = aImage.GetBitmapEx();
+b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor());
+aImage = Image(b);
+}
+
+m_pBmp-SetImage( aImage );
// determine size and type
OUString aSizeText( m_aUnknownSize );
diff --git a/sfx2/source/sidebar/DeckLayouter.cxx
b/sfx2/source/sidebar/DeckLayouter.cxx
index 9dcc358..c87625b 100644
--- a/sfx2/source/sidebar
Re: Hi-DPI patches for 4.2
On Tue, Mar 11, 2014 at 4:57 AM, Norbert Thiebaud nthieb...@gmail.com wrote: On Tue, Mar 11, 2014 at 3:53 AM, Keith Curtis keit...@gmail.com wrote: That picture is bizarre in that the gridlines drawn by Calc are not being doubled. Have you fiddled with the OS DPI stuff? The grid lines are not bitmap, they are vector drawing... but more importantly... _WITH_ the #ifdef to prevent the meddling with bitmap everything looks 'fine'. Yes, but according to the docs, in compatibility mode, Any vector-based drawing performed by an app is scaled for high resolution https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW5 The Mac LibreOffice screenshots in bug reports I have seen have doubled vector drawing. I think there is something wrong with your build. In any case, if you feel something should be done for the Mac, the simplest thing is to add two #ifdefs to force the DPIScaleFactor to 1 for the Mac: https://gerrit.libreoffice.org/#/c/8516/1/vcl/source/window/window.cxx,cm That would turn off all bitmap doubling in a very localized place. What do you think about that? -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Hi-DPI patches for 4.2
Well, the rabbit hole gets deeper. Norbert, it now seems to me that there isn't something wrong with your build, but with your OS!?! Here is a screenshot of the current released build on Retina for comparison: http://nabble.documentfoundation.org/file/n4101006/Screen_Shot_2014-03-11_at_17.49.30.png It generally looks fine, and doesn't need improvements. In it, you can see that the Calc gridlines are two pixels wide as expected because of the app scaling. (For comparison, on Linux, they are always one pixel wide which is perhaps not ideal but looks okay.) However, the gridlines are effectively the same width as yours. But look at the close buttons. I've zoomed in both to make it clearer. The one on the left is from the screenshot above, and the one on the right is from your screenshot last night. http://nabble.documentfoundation.org/file/n4101006/CloseButtons.png It seems as if all of Norbert's pixels are doubled. How does this relate to the compatibility mode and DPI scale factor? I don't know WTF is going on and it is time-consuming without any hardware to try things. It seems there are possibly two problems on Norbert's machine. If the OS really gives the wrong DPI even in compatibility mode, which doesn't seem correct but is of course possible, then the simplest way disable these patches on the Mac is to just force mnDPIScaleFactor to 1. In that case, these patches would behave as it does on 4.2.1. This can be done with 2 #ifndefs in window.cxx and should achieve a similar result as disabling the bitmap doubling all over the place. Norbert, can you try that? Mac doesn't need this code as much as Win / Linux so there needs a simple way to decouple them. I was quite certain when Norbert had sent out his first mail to this thread saying there were problems with these patches that he had forgotten about what happens in compatibility mode is on -- because he'd been spending all of his time working with the off case. But I never imagined it would be this complicated. It would be nice to have these patches not held up by the Mac as they are right now. -Keith -- View this message in context: http://nabble.documentfoundation.org/Hi-DPI-patches-for-4-2-tp4100852p4101006.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Hi-DPI patches for 4.2
Perhaps it would be good to have Norbert double-check his work, but it seems logical the later changes aren't necessary without his first retina change to turn off auto-doubling mode, which is not a part of this set. Norbert is still in the investigation phase, and there are multiple ways to implement this on the Mac, so there is no need to optimize for cleanliness until it works. It should be put in the release notes that this is for Linux and Windows only as Mac will still run in compatibility mode. Doubling bitmaps is a hack but since bigger bitmaps don't exist, it is better than doing nothing. I haven't looked into the low-level resource loading code, but there are very probably VCL changes required once those new bitmaps are created. Once that happens, then the doubling code can be removed, but only at the end, and it might be a while given how many bitmaps exist in all the icon packs out there. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Hi-DPI patches for 4.2
On Mon, Mar 10, 2014 at 7:15 PM, Norbert Thiebaud nthieb...@gmail.com wrote: On Mon, Mar 10, 2014 at 4:51 PM, Keith Curtis keit...@gmail.com wrote: Doubling bitmaps is a hack but since bigger bitmaps don't exist, it is better than doing nothing. The problem is that mac, in compatibility mode, already auto-double.. so we end-up with a quadrupling of the bitmap, which mean you in the end only see a quarter of the intended icon. Have you made a build with it turned back on? I ask because it doesn't make sense the OS would return DPI != 96 while in auto-doubling mode. That would seemingly break the backward compatibility support the Mac is trying to achieve. Thanks, -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: drawinglayer/source editeng/source include/vcl sw/source vcl/source
drawinglayer/source/processor2d/helperwrongspellrenderer.cxx | 14
editeng/source/editeng/impedit3.cxx | 16
include/vcl/outdev.hxx |7 --
sw/source/core/inc/wrong.hxx |7 --
sw/source/core/txtnode/fntcache.cxx | 34 --
vcl/source/gdi/outdev3.cxx | 37 +++
6 files changed, 22 insertions(+), 93 deletions(-)
New commits:
commit ff6f3164dfc454354bee79eac30d6cc279b8a0ec
Author: Keith Curtis keit...@gmail.com
Date: Sat Feb 22 05:30:00 2014 -0500
Simplify DrawWave
This patch simplifies the DrawWave logic. Callers of that code would try to
figure out what size wave to draw and pass down a style integer to
DrawWaveLine, but DrawWaveLine already has logic which trims the height of
the
wave so it doesn't need the hint.
This doesn't change the UNO API
(::com::sun::star::awt::FontUnderline::SMALLWAVE), but it does get rid of
internal usages and maps those small waves to normal.
Note that changing the zoom in Calc right now causes spelling underlines to
disappear. That bug is not related to these changes.
Conflicts:
editeng/source/editeng/impedit3.cxx
Change-Id: I3caa2a74a0f5228b924d4e1b0a77f96eaef5fa00
Reviewed-on: https://gerrit.libreoffice.org/8168
Tested-by: Caolán McNamara caol...@redhat.com
Reviewed-by: Caolán McNamara caol...@redhat.com
diff --git a/drawinglayer/source/processor2d/helperwrongspellrenderer.cxx
b/drawinglayer/source/processor2d/helperwrongspellrenderer.cxx
index 8d1e69f..13a015f 100644
--- a/drawinglayer/source/processor2d/helperwrongspellrenderer.cxx
+++ b/drawinglayer/source/processor2d/helperwrongspellrenderer.cxx
@@ -42,8 +42,6 @@ namespace drawinglayer
const sal_uInt32
nFontPixelHeight(basegfx::fround(aFontVectorPixel.getLength()));
static const sal_uInt32 nMinimumFontHeight(5); // #define
WRONG_SHOW_MIN 5
-static const sal_uInt32 nSmallFontHeight(11); // #define
WRONG_SHOW_SMALL 11
-static const sal_uInt32 nMediumFontHeight(15); // #define
WRONG_SHOW_MEDIUM 15
if(nFontPixelHeight nMinimumFontHeight)
{
@@ -51,16 +49,6 @@ namespace drawinglayer
const basegfx::B2DPoint aStop(aLocalTransform *
basegfx::B2DPoint(rWrongSpellCandidate.getStop(), 0.0));
const Point aVclStart(basegfx::fround(aStart.getX()),
basegfx::fround(aStart.getY()));
const Point aVclStop(basegfx::fround(aStop.getX()),
basegfx::fround(aStop.getY()));
-sal_uInt16 nWaveStyle(WAVE_FLAT);
-
-if(nFontPixelHeight nMediumFontHeight)
-{
-nWaveStyle = WAVE_NORMAL;
-}
-else if(nFontPixelHeight nSmallFontHeight)
-{
-nWaveStyle = WAVE_SMALL;
-}
// #i101075# draw it. Do not forget to use the evtl. offsetted
origin of the target device,
// e.g. when used with mask/transparence buffer device
@@ -72,7 +60,7 @@ namespace drawinglayer
rOutputDevice.EnableMapMode(false);
rOutputDevice.SetLineColor(Color(aProcessedColor));
rOutputDevice.SetFillColor();
-rOutputDevice.DrawWaveLine(aOrigin + aVclStart, aOrigin +
aVclStop, nWaveStyle);
+rOutputDevice.DrawWaveLine(aOrigin + aVclStart, aOrigin +
aVclStop);
rOutputDevice.EnableMapMode(bMapModeEnabledState);
}
diff --git a/editeng/source/editeng/impedit3.cxx
b/editeng/source/editeng/impedit3.cxx
index 1ee1a1b..c095ba2 100644
--- a/editeng/source/editeng/impedit3.cxx
+++ b/editeng/source/editeng/impedit3.cxx
@@ -83,8 +83,6 @@ using namespace ::com::sun::star::linguistic2;
#define RESDIFF 10
#define WRONG_SHOW_MIN 5
-#define WRONG_SHOW_SMALL11
-#define WRONG_SHOW_MEDIUM 15
struct TabInfo
{
@@ -169,14 +167,6 @@ static void lcl_DrawRedLines(
long nHght = pOutDev-LogicToPixel( Size( 0, nFontHeight ) ).Height();
if( WRONG_SHOW_MIN nHght )
{
-sal_uInt16 nStyle;
-if( WRONG_SHOW_MEDIUM nHght )
-nStyle = WAVE_NORMAL;
-else if( WRONG_SHOW_SMALL nHght )
-nStyle = WAVE_SMALL;
-else
-nStyle = WAVE_FLAT;
-
size_t nEnd, nStart = nIndex;
bool bWrong = pWrongs-NextWrong( nStart, nEnd );
while ( bWrong )
@@ -189,12 +179,12 @@ static void lcl_DrawRedLines(
if ( nEnd nMaxEnd )
nEnd = nMaxEnd;
Point aPnt1( rPnt );
-if ( bVertical ( nStyle != WAVE_FLAT ) )
+if ( bVertical )
{
// VCL doesn't know that the text is vertical, and is
manipulating
// the positions a little bit in y direction...
long nOnePixel = pOutDev
[Libreoffice-commits] core.git: vcl/inc vcl/unx
vcl/inc/unx/saldisp.hxx |2 --
vcl/unx/generic/app/saldisp.cxx | 23 ---
vcl/unx/generic/gdi/salgdi.cxx |8 ++--
3 files changed, 6 insertions(+), 27 deletions(-)
New commits:
commit 9f308fbc02439e25f8932314a9374c205ebdbc4c
Author: Keith Curtis keit...@gmail.com
Date: Fri Feb 21 19:21:27 2014 -0500
Simplify resolution calculation
Removed unnecessary complexity with resolutions because X in 2014 isn't
telling the truth about the size of the screen. My brand-new 13 laptop
with the latest X and everything apparently has a 33 x 18 monitor. So
if the data isn't reliable, just use 96 dpi anyway which is a very
reasonable default.
Also got rid of exact resolution member variable. LibreOffice can just
always think it has exact resolution. If it doesn't, then it just means
the code needs to be smarter, not that we need a flag about whether the
data we have is exact or not.
Change-Id: Ic41bdc3a82dbd1fdb6a987d6dc49adad8194ce14
Reviewed-on: https://gerrit.libreoffice.org/8166
Reviewed-by: Caolán McNamara caol...@redhat.com
Tested-by: Caolán McNamara caol...@redhat.com
diff --git a/vcl/inc/unx/saldisp.hxx b/vcl/inc/unx/saldisp.hxx
index 1125608..9b98a76 100644
--- a/vcl/inc/unx/saldisp.hxx
+++ b/vcl/inc/unx/saldisp.hxx
@@ -252,7 +252,6 @@ protected:
std::vector ScreenData m_aScreens;
ScreenData m_aInvalidScreenData;
PairaResolution_; // [dpi]
-boolmbExactResolution;
sal_uLong nMaxRequestSize_; // [byte]
srv_vendor_tmeServerVendor;
@@ -353,7 +352,6 @@ public:
const SalVisual GetVisual( SalX11Screen nXScreen ) const { return
getDataForScreen(nXScreen).m_aVisual; }
RenderEntryMap GetRenderEntries( SalX11Screen nXScreen ) const {
return getDataForScreen(nXScreen).m_aRenderData; }
const Pair GetResolution() const { return aResolution_; }
-boolGetExactResolution() const { return mbExactResolution; }
sal_uLong GetProperties() const { return PROPERTY_DEFAULT; }
sal_uLong GetMaxRequestSize() const { return nMaxRequestSize_; }
XLIB_Time GetLastUserEventTime( bool bAlwaysReget = false ) const;
diff --git a/vcl/unx/generic/app/saldisp.cxx b/vcl/unx/generic/app/saldisp.cxx
index c343552..99060cd 100644
--- a/vcl/unx/generic/app/saldisp.cxx
+++ b/vcl/unx/generic/app/saldisp.cxx
@@ -540,7 +540,7 @@ void SalDisplay::Init()
int nDisplayScreens = ScreenCount( pDisp_ );
m_aScreens = std::vectorScreenData(nDisplayScreens);
-mbExactResolution = false;
+bool bExactResolution = false;
/* #i15507#
* Xft resolution should take precedence since
* it is what modern desktops use.
@@ -554,27 +554,12 @@ void SalDisplay::Init()
if( (nDPI = 50) (nDPI = 500) )
{
aResolution_ = Pair( nDPI, nDPI );
-mbExactResolution = true;
+bExactResolution = true;
}
}
-if( mbExactResolution == false )
+if( bExactResolution == false )
{
-int nDisplayWidth = DisplayWidthMM ( pDisp_,
m_nXDefaultScreen.getXScreen() );
-int nDisplayHeight = DisplayHeightMM( pDisp_,
m_nXDefaultScreen.getXScreen() );
-
-if (nDisplayHeight == 0 || nDisplayWidth == 0)
-{
-aResolution_ = Pair( 96, 96 );
-SAL_WARN(vcl, screen width/height reported as 0!, using
fallback 96dpi);
-}
-else
-{
-aResolution_ =
-Pair( DPI( WidthOfScreen( DefaultScreenOfDisplay( pDisp_ ) ),
- nDisplayWidth ),
- DPI( HeightOfScreen( DefaultScreenOfDisplay( pDisp_ ) ),
- nDisplayHeight ) );
-}
+aResolution_ = Pair( 96, 96 );
}
nMaxRequestSize_= XExtendedMaxRequestSize( pDisp_ ) * 4;
diff --git a/vcl/unx/generic/gdi/salgdi.cxx b/vcl/unx/generic/gdi/salgdi.cxx
index 018f833..c4b9cf9 100644
--- a/vcl/unx/generic/gdi/salgdi.cxx
+++ b/vcl/unx/generic/gdi/salgdi.cxx
@@ -484,12 +484,8 @@ void X11SalGraphics::GetResolution( sal_Int32 rDPIX,
sal_Int32 rDPIY ) // cons
rDPIX = pDisplay-GetResolution().A();
rDPIY = pDisplay-GetResolution().B();
-if( !pDisplay-GetExactResolution() rDPIY 96 )
-{
-rDPIX = Divide( rDPIX * 96, rDPIY );
-rDPIY = 96;
-}
-else if ( rDPIY 200 )
+
+if ( rDPIY 200 )
{
rDPIX = Divide( rDPIX * 200, rDPIY );
rDPIY = 200;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: Testing/Working on PyUNO?
Hi; The C/C++ groups I worked in had all testers working in a scripting language. Those who had the skills and interest to write in C/C++ moved to product code. It was easy for developers to debug problems because the test application allowed you to configure which tests to run, the IDE was easy to use with single-step debugging, etc. You'd need two debuggers running, but it worked great and was little slower than working with C++ tests. In the situation here, I agree that unit tests should be in C++, typically written by the developers when they write their code. However, there can still be room for further testing in Python. I've seen code that would call random APIs with random values and via genetic algorithms would come up with good ways to stress and crash the product. It would find plenty of bugs that no unit test ever could. The test harness was very good, it only reported problems that were reproducible, and the app would narrow it down to the shortest number of steps. So perhaps it is good to figure out whether something is a unit test, a UNO test, or some other fancier kind of testing. If a developer doesn't want to run Python, they can just look at the stack trace and try to figure it out on their own similar to what happens when bugs are reported today. Python just makes it more reproducible. It also seems that people who are interested in Python today could work on making it easier to contribute to LibreOffice in Python. There is a small community of Python hackers contributing to today, mostly it seems it is just Xisco Fauli. You don't need to re-write the whole app in Python to bring in new people, as there are already plenty of places to contribute, especially if you consider Base ;-) I find more and more programmers who don't have C++ experience, meanwhile Python is one of the fastest growing languages. Regards, -Keith -- View this message in context: http://nabble.documentfoundation.org/Re-Testing-Working-on-PyUNO-tp4097868p4097981.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Testing/Working on PyUNO?
Hi Markus, Thanks for the explanation. I've recently been talking to lots of younger programmers and so wanted to write a few words. It is a conundrum to me why you have a quite large C++ team, but not many people supplementing and polishing in Python, especially given they should be easier to find. They are out there! Regards, -Keith On Wed, Feb 19, 2014 at 6:50 PM, Markus Mohrhard markus.mohrh...@googlemail.com wrote: Hey Keith, On Wed, Feb 19, 2014 at 6:47 PM, Keith Curtis keit...@gmail.com wrote: Hi; The C/C++ groups I worked in had all testers working in a scripting language. Those who had the skills and interest to write in C/C++ moved to product code. It was easy for developers to debug problems because the test application allowed you to configure which tests to run, the IDE was easy to use with single-step debugging, etc. You'd need two debuggers running, but it worked great and was little slower than working with C++ tests. So we are not really discussing about python tests in general. I'm sorry if that was the impression. For out-of-process tests python tests are arguably the best choice. It is however much more complicated when it comes to in-process tests. We already use out-of-process python tests like the crash testing or convwatch. The whole discussion was mostly where python tests make sense in our build as in-process tests. In the situation here, I agree that unit tests should be in C++, typically written by the developers when they write their code. However, there can still be room for further testing in Python. I've seen code that would call random APIs with random values and via genetic algorithms would come up with good ways to stress and crash the product. It would find plenty of bugs that no unit test ever could. The test harness was very good, it only reported problems that were reproducible, and the app would narrow it down to the shortest number of steps. So perhaps it is good to figure out whether something is a unit test, a UNO test, or some other fancier kind of testing. If a developer doesn't want to run Python, they can just look at the stack trace and try to figure it out on their own similar to what happens when bugs are reported today. Python just makes it more reproducible. So for UNO it makes sense to use python instead of our current java tests (I still would prefer C++ as it is easier to debug but python already allows in-process tests). However calling something through UNO or in the UI often takes different code paths. That means if a test through the API fails you can't just try to reproduce it in the UI and see if you can debug it there. On the other hand looking at the API documentation and writing a test FOR the API can be done perfectly find in python (with the exception that is still a bit more difficult to debug). It also seems that people who are interested in Python today could work on making it easier to contribute to LibreOffice in Python. There is a small community of Python hackers contributing to today, mostly it seems it is just Xisco Fauli. You don't need to re-write the whole app in Python to bring in new people, as there are already plenty of places to contribute, especially if you consider Base ;-) I find more and more programmers who don't have C++ experience, meanwhile Python is one of the fastest growing languages. I mostly agree. IMO we have many tasks perfectly in the scope of python scripting where python is the best tool for the job. So it is not like the project does not value great python developers and if there are people out there who only know python and want to contribute we are not short of nice and important tasks. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Unity for HiDPI
Hi Björn, I have done some reading that the next version of Unity is going to have HiDPI support. Do you know if they will return 192 DPI when on these screens like what Gnome 3.10 does? I could find some Unity alias and ask, but you might know or be able to encourage them ;-) Unfortunately, I can't easily install Unity to test because I'd have to replace a lot of my other core packages. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
KDE and HiDPI
Hi; I did some research for KDE and DPI. By default all windows are 96 DPI and there is no screen auto-detection. However, it is possible to manually set the DPI for KDE 4.x. In the system settings, you can click on Appearance - Fonts and there is an option to force fonts DPI to 192 or whatever. Fortunately, that setting applies to more than fonts. When 192 is set, the HiDPI mode kicks in for LibreOffice and it looks great. I've read about more work happening for HiDPI in QT5 / KDE 5 which should be out in the first-half of this year, but fortunately things can be made to look fine with current code. I'll put some updated comments about this in the wiki page also. Between all the DEs, and other OSes, the test matrix for LibreOffice is large. Regards, -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Some information about LibO on actual hardware
I have the same hardware, but running Linux. There are a number of fixes in the master branch, and hope to get them into 4.2.1. It should just work on 8.1, but I am very curious to find out find out what happens as no one yet has tried. You are the first person with a Windows HiDPI machine around, so I hope you can try out another pre-release of 4.2.1 and give feedback? I checked and Cebit is March 10th so that gives time to have something better to show. As for the hang, I saw it on Linux when trying to widen the sidebar past its maximum width when the window had already been set wider than it should by another part of the code which didn't respect the max value. I increased the maximum width allowed for the Sidebar which should make the problem usually go away ;-) You might be seeing another problem of course, your testing would be helpful. -Keith -- View this message in context: http://nabble.documentfoundation.org/Some-information-about-LibO-on-actual-hardware-tp4097784p4097819.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
HiDPI for Mac, Windows, etc.
Hi; Norbert has done a patch to master that should turn off the Mac auto-doubling mode, but it doesn't appear to be doing anything. This is confusing, but once it does work, then people can begin to decide whether the benefits outweigh the disadvantages of turning off compatibility mode now. (If not, then what should be done to tip the balance?) Also, no one has of yet tried to see what happens on Windows and no one has responded with the right hardware on the QA alias: http://nabble.documentfoundation.org/Libreoffice-qa-HiDPI-testing-for-LibreOffice-4-2-1-td4095055.html If the patches can get into a pre-release, it can get out to more people who can find or help fix problems. The change should be quite safe in that it only kicks in when the OS returns =144 dpi. One can almost think of this as an experimental mode because so few OSes return that currently. This means it won't enable the behavior in a number of machines that need it, but it should be enough to be worthwhile, and allow input from more people. I could try to submit a patch to enable it for more DEs and versions of Windows, but it is perhaps better to be conservative initially. Xfce already allows you to set the DPI. Maybe the next version of Unity will be smart enough to return 192 dpi sometimes like Gnome 3.10 does? It would be nice to get some testing on Ubuntu. I'm not sure what to do next, and so I email you. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-qa] HiDPI testing for LibreOffice 4.2.1
Hi; I think it would be good to get some basic level of support for hidpi into LibreOffice 4.2.1: https://wiki.documentfoundation.org/Development/HiDpi The code has been in master since late December and there have been fixes already: http://nabble.documentfoundation.org/Font-size-dropdown-regression-td4094349.html Does anyone have such a laptop running Linux or Windows to do some testing? Norbert has done some initial Mac work but it isn't enough to turn off the compatibility mode yet: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9e4d9b223a0593686bee800484de3c23095d4f Please cc, not on list. -Keith ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Font size dropdown regression
Hi; Sorry for causing bug: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8138c07b984ba1654483b4dc3488820ca4deaaca https://bugs.freedesktop.org/show_bug.cgi?id=73051 I'm not exactly sure what is going on, but on my HiDPI machine with the 30 value I can fit 7 digits! Too many is better than too few but I had tried to improve. I have been worried about that change so now that it is reverted, I don't have to anymore: http://nabble.documentfoundation.org/Font-style-and-size-dropdown-widths-td4087999.html -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Font size dropdown regression
Just a quick follow up. After sending that mail, I noticed Caolán made a better fix: http://cgit.freedesktop.org/libreoffice/core/commit/?id=780eb9f704e7a61f43624a2c03b4f6a15647a1a1 I've just now finished a build and can confirm it looks great. Thank you... -Keith On Tue, Jan 28, 2014 at 12:00 PM, Keith Curtis keit...@gmail.com wrote: Hi; Sorry for causing bug: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8138c07b984ba1654483b4dc3488820ca4deaaca https://bugs.freedesktop.org/show_bug.cgi?id=73051 I'm not exactly sure what is going on, but on my HiDPI machine with the 30 value I can fit 7 digits! Too many is better than too few but I had tried to improve. I have been worried about that change so now that it is reverted, I don't have to anymore: http://nabble.documentfoundation.org/Font-style-and-size-dropdown-widths-td4087999.html -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
HiDPI OS-specific issues / next steps
Hi; I've got another patchset I've submitted to Gerrit. Assuming that goes okay, the next steps are: * test / figure out what the most important issues are * whether / how to enable it for the Mac (Currently LibreOffice runs in compatibility mode where things are auto-doubled.) * testing on various Windows versions * what to do for KDE, Xfce, Unity, etc. I only have Gnome / KDE / Xfce installed so I can only work on those scenarios. Advice / help appreciated. It seems it could take a minor release to work through some of these details. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: cui/source sd/source svx/source sw/source vcl/source
cui/source/tabpages/align.cxx |2 +-
cui/source/tabpages/border.cxx |4 ++--
sd/source/ui/sidebar/LayoutMenu.cxx|2 +-
svx/source/stbctrls/modctrl.cxx|2 +-
svx/source/stbctrls/pszctrl.cxx|4 ++--
svx/source/stbctrls/selctrl.cxx|2 +-
svx/source/stbctrls/xmlsecctrl.cxx |2 +-
svx/source/stbctrls/zoomsliderctrl.cxx |2 +-
sw/source/ui/utlui/viewlayoutctrl.cxx |2 +-
vcl/source/window/toolbox2.cxx |2 +-
10 files changed, 12 insertions(+), 12 deletions(-)
New commits:
commit ab56275f4622ade0286a580a5945600567c6b415
Author: Keith Curtis keit...@gmail.com
Date: Thu Jan 2 16:36:51 2014 +0100
hidpi: Really use BMP_SCALE_FAST when scaling the images.
It is not a problem of performance, but of the look - the images get too
blurry in the case of icons; and the blurry look is worse than than the
artifacts of the fast scaling.
Revert hidpi: Use the default scaling algorithm.
This reverts commit e07097cce36f1220f5574a80dc22eeabb3005261.
Change-Id: I8af2827758e02ec3c8b7dade1559c45bd9f0ef35
diff --git a/cui/source/tabpages/align.cxx b/cui/source/tabpages/align.cxx
index 2418ff5..5ba830a 100644
--- a/cui/source/tabpages/align.cxx
+++ b/cui/source/tabpages/align.cxx
@@ -329,7 +329,7 @@ void AlignmentTabPage::InitVsRefEgde()
{
OUString rImageName = aImageList.GetImageName(i);
BitmapEx b = aImageList.GetImage(rImageName).GetBitmapEx();
-b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor());
+b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor(), BMP_SCALE_FAST);
aImageList.ReplaceImage(rImageName, Image(b));
}
}
diff --git a/cui/source/tabpages/border.cxx b/cui/source/tabpages/border.cxx
index 31bb802..0073a9e 100644
--- a/cui/source/tabpages/border.cxx
+++ b/cui/source/tabpages/border.cxx
@@ -134,7 +134,7 @@ SvxBorderTabPage::SvxBorderTabPage(Window* pParent, const
SfxItemSet rCoreAttrs
{
OUString rImageName = aBorderImgLst.GetImageName(i);
BitmapEx b = aBorderImgLst.GetImage(rImageName).GetBitmapEx();
-b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor());
+b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor(), BMP_SCALE_FAST);
aBorderImgLst.ReplaceImage(rImageName, Image(b));
}
@@ -142,7 +142,7 @@ SvxBorderTabPage::SvxBorderTabPage(Window* pParent, const
SfxItemSet rCoreAttrs
{
OUString rImageName = aShadowImgLst.GetImageName(i);
BitmapEx b = aShadowImgLst.GetImage(rImageName).GetBitmapEx();
-b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor());
+b.Scale(GetDPIScaleFactor(), GetDPIScaleFactor(), BMP_SCALE_FAST);
aShadowImgLst.ReplaceImage(rImageName, Image(b));
}
}
diff --git a/sd/source/ui/sidebar/LayoutMenu.cxx
b/sd/source/ui/sidebar/LayoutMenu.cxx
index 55a9157..5abb05c 100644
--- a/sd/source/ui/sidebar/LayoutMenu.cxx
+++ b/sd/source/ui/sidebar/LayoutMenu.cxx
@@ -651,7 +651,7 @@ void LayoutMenu::Fill (void)
BitmapEx aBmp(SdResId(pInfo-mnBmpResId));
if (GetDPIScaleFactor() 1)
-aBmp.Scale(GetDPIScaleFactor(), GetDPIScaleFactor());
+aBmp.Scale(GetDPIScaleFactor(), GetDPIScaleFactor(),
BMP_SCALE_FAST);
if (bRightToLeft (WritingMode_TB_RL != pInfo-meWritingMode))
aBmp.Mirror (BMP_MIRROR_HORZ);
diff --git a/svx/source/stbctrls/modctrl.cxx b/svx/source/stbctrls/modctrl.cxx
index 5689079..db94f49 100644
--- a/svx/source/stbctrls/modctrl.cxx
+++ b/svx/source/stbctrls/modctrl.cxx
@@ -78,7 +78,7 @@ SvxModifyControl::SvxModifyControl( sal_uInt16 _nSlotId,
sal_uInt16 _nId, Status
for (int i = 0; i mpImpl-MODIFICATION_STATE_SIZE; i++)
{
BitmapEx b = mpImpl-maImages[i].GetBitmapEx();
-b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor());
+b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor(),
BMP_SCALE_FAST);
mpImpl-maImages[i] = Image(b);
}
}
diff --git a/svx/source/stbctrls/pszctrl.cxx b/svx/source/stbctrls/pszctrl.cxx
index bc2caa0..733b8e7 100644
--- a/svx/source/stbctrls/pszctrl.cxx
+++ b/svx/source/stbctrls/pszctrl.cxx
@@ -180,11 +180,11 @@ SvxPosSizeStatusBarControl::SvxPosSizeStatusBarControl(
sal_uInt16 _nSlotId,
if ( rStb.GetDPIScaleFactor() 1)
{
BitmapEx b = pImp-aPosImage.GetBitmapEx();
-b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor());
+b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor(),
BMP_SCALE_FAST);
pImp-aPosImage = Image(b);
b = pImp-aSizeImage.GetBitmapEx();
-b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor());
+b.Scale(rStb.GetDPIScaleFactor(), rStb.GetDPIScaleFactor(),
BMP_SCALE_FAST);
pImp-aSizeImage = Image(b);
}
diff
Keith Curtis license statement
All of my past future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] HiDPI fixes for squiggly underlines
HI Kendy, Thank you! I've pulled your diff and doing a rebuild now. I have found that 5 pixels is a good value on my machine but I'll try 6, and it needs to be shifted down one more pixel. Also, there may be dirt because it increases the waveheight after the check. I believe Linux will return 96 dpi, but I will check all this and improve as necessary, code against the new OutDev value, and submit an initial set of fixes to Gerrit. The toolbar work was being handled by Andrzej so I'll work on the other aspects. I've focused on Writer, because that is what I use the most, but many of the changes help all the apps and I've done some work in Calc and Impress also. I've made one fix in the Sidebar, but it needs a few hours by someone who knows the code, or a few days by someone who doesn't. It would be great to get this in somehow as things are much prettier already. I do this work because it is fun and easy, but there isn't much value in icons and controls too small to easily recognize or click on. Regards, -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Disabling unit tests, redux
Okay, I took it out. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] HiDPI fixes for squiggly underlines
Hi Kendy, I had no idea to where to put this so I appreciate your help. I verified your idea works for all of the places I worked on so far because it can get to a Window. If there were static constructors that loaded and cached shared bitmaps, I think it could be a problem, but the earliest I've found yet is control instance construction. Thanks! -Keith On Wed, Dec 18, 2013 at 4:07 PM, Jan Holesovsky ke...@collabora.com wrote: Hi Keith, Keith Curtis píše v Pá 13. 12. 2013 v 15:58 -0500: Good to hear from you. I've got a number of things in progress on my computer beyond the underlines (https://wiki.documentfoundation.org/Development/HiDpi) but I wait to get an API first as I'm just writing if (1) //hidpi. I am sorry it takes me so long to get back to you - I am trying to find out the best place for this, so that we have the smallest amount of places to touch; unfortunately each experiment triggered a ~whole LibreOffice rebuild, so it is progressing slowly. What looks best at the moment is just adding it to OutputDevice, next to mnDPIX and mnDPIY; looks most promising that way. I believe with this, we will be able to do the scaling directly in vcl in case the OutputDevice is in fact a Window. I hope to have some results tomorrow; again - sorry that it takes so long. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Disabling unit tests, redux
I don't even know the names of the various modules I'm working in and prefer to let the smart system figure it out ;-) make build-nocheck works great and things run so much faster on my little laptop. Thank you. I put this info in the wiki to save questions in the future. -Keith On Mon, Dec 16, 2013 at 1:33 AM, Khaled Hosny khaledho...@eglug.org wrote: On Mon, Dec 16, 2013 at 12:56:59AM -0500, Keith Curtis wrote: It appears when making changes to individual C++ files that my computer spends about 90% of the build time running unit tests. It seems that ‘make foo.build’ will not run the tests, at least this is what I “discovered” few days ago. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Disabling unit tests, redux
It appears when making changes to individual C++ files that my computer spends about 90% of the build time running unit tests. I tried make -sr all to disable them, but it still ran lots: http://lists.freedesktop.org/archives/libreoffice/2011-March/009422.html I tried hacking on the makefile but got lost. Can this shortcut be re-enabled or is there a new way now? Sometimes, you just want to add a printf. The build process works great otherwise. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] HiDPI fixes for squiggly underlines
Hi Kendy, Good to hear from you. I've got a number of things in progress on my computer beyond the underlines ( https://wiki.documentfoundation.org/Development/HiDpi) but I wait to get an API first as I'm just writing if (1) //hidpi. I personally don't think a floating point value is a good idea. At the lowest level, pixel line widths go to 2 or 3 and in the square case go to 4 or 9. I believe anything who wants more resolution should probably be working based on the system font size. The changes I'm making don't seem to need more than 3 and even 2 is plenty for all laptops today and into the distant future. Floating point arithmetic used to be a lot slower than integer as well but I don't know if that is still true ;-) I hope it is okay if I can write code that handles the 2x case but has no guarantees about any other value. I can't test what I can't see and there is a fair amount of work to get LibreOffice looking good and supporting variable-sized bitmaps at all. So if it were up to me, I'd just make it a boolean for a while, and focus / force that part to look great everywhere. Then when you were ready to further generalize it, the compiler would make you to validate all the areas. I even have been taking advantage of the simplicity. I found some arrow drawing logic that wanted an odd-sized height for best results. And so I just doubled it and subtracted one ;-) My biggest concern wrt the API is that it has the right value out of the box. For example, what do normal Macs return for the system font size versus Retinas? What about on Windows? There is plenty of intelligence that can go into a bit. Putting the change in ImplDrawWaveLine is possible. My change is safer in that it mostly only touches the spelling / grammar which is the most noticeable issue. With ImplDrawWaveLine you have to worry about more callers, printers, etc. and possibilities for dirt on screen. I wouldn't necessarily recommend shifting down 2 pixels for the low-level drawing code, so maybe you'd still have to have changes in both places. ImplDrawWaveLine is a routine takes a pixel line width as input, so perhaps the policy decision should be above it. It seems sort of like putting the bitmap doubling logic into the BitBlt routine versus in the toolbar which loads the bitmaps. I could look at the wavy underline character property logic, but I think it is low priority and still might not change the ImplDrawWaveLine. I haven't looked into it. I'm happy to fix any bugs in my simple code, but get concerned about suggestions that complicate it ;-) Working on this early next week would be great. I've got about 600 more lines in 14 files to review that make a difference. There is a fair amount of low-hanging fruit. I am possibly stuck on two issues, but I plug away on it as I have free time. The hardest part is finding the actual line of code that have the bug. With my work, they are being marked which makes future work easier. I did see code that is possibly problematic in places like DecoView but I'm just focusing on the visible ones. Toolbar bitmaps are the most important. The Sidebar is the most broken. Do you think they will fix it? Anyway, I look forward to working through the issues soon because I have some time now and hopefully getting this into 4.2. -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] HiDPI fixes for squiggly underlines
Unfortunately, there is no resolution-independent back-end as the interface from LibreOffice to the OS is in discrete pixels and it has made extensive use of that ubiquitous design. I agree for user-created objects such as arrows and such, things should be defined in terms of resolution-independent values and zoomablee. However, the character property for underlining doesn't let you choose precise widths except for normal and bold. Squiggly underlines give you no choice as it isn't important and can be decided for you independently of zoom or font size. As higher-resolution or scalable bitmaps are designed, hidpi logic can be removed, but in the short to medium term, LibreOffice has places that draw things, and an easy and safe fix is to double it, and possibly triple it. There is perhaps a chance you don't need 3x for mobile because the eyes are closer to the screen. The vast majority of LibreOffice works as you say and the rest can invisibly and steadily move that way over time. There are plenty of ways to improve the widget layers. Consider also that if you scaled the 16 pixel-wide toolbar buttons to 19 pixels, you wouldn't like the result. Getting it to work well with 1x and 2x is just the start. Regards, -Keith On Fri, Dec 13, 2013 at 4:40 PM, Tomaž Vajngerl qui...@gmail.com wrote: Hi, On Fri, Dec 13, 2013 at 9:58 PM, Keith Curtis keit...@gmail.com wrote: Hi Kendy, Good to hear from you. I've got a number of things in progress on my computer beyond the underlines (https://wiki.documentfoundation.org/Development/HiDpi) but I wait to get an API first as I'm just writing if (1) //hidpi. I personally don't think a floating point value is a good idea. At the lowest level, pixel line widths go to 2 or 3 and in the square case go to 4 or 9. I believe anything who wants more resolution should probably be working based on the system font size. The changes I'm making don't seem to need more than 3 and even 2 is plenty for all laptops today and into the distant future. Floating point arithmetic used to be a lot slower than integer as well but I don't know if that is still true ;-) I hope it is okay if I can write code that handles the 2x case but has no guarantees about any other value. I can't test what I can't see and there is a fair amount of work to get LibreOffice looking good and supporting variable-sized bitmaps at all. So if it were up to me, I'd just make it a boolean for a while, and focus / force that part to look great everywhere. Then when you were ready to further generalize it, the compiler would make you to validate all the areas. I even have been taking advantage of the simplicity. I found some arrow drawing logic that wanted an odd-sized height for best results. And so I just doubled it and subtracted one ;-) My biggest concern wrt the API is that it has the right value out of the box. For example, what do normal Macs return for the system font size versus Retinas? What about on Windows? There is plenty of intelligence that can go into a bit. Putting the change in ImplDrawWaveLine is possible. My change is safer in that it mostly only touches the spelling / grammar which is the most noticeable issue. With ImplDrawWaveLine you have to worry about more callers, printers, etc. and possibilities for dirt on screen. I wouldn't necessarily recommend shifting down 2 pixels for the low-level drawing code, so maybe you'd still have to have changes in both places. ImplDrawWaveLine is a routine takes a pixel line width as input, so perhaps the policy decision should be above it. It seems sort of like putting the bitmap doubling logic into the BitBlt routine versus in the toolbar which loads the bitmaps. I could look at the wavy underline character property logic, but I think it is low priority and still might not change the ImplDrawWaveLine. I haven't looked into it. I'm happy to fix any bugs in my simple code, but get concerned about suggestions that complicate it ;-) Working on this early next week would be great. I've got about 600 more lines in 14 files to review that make a difference. There is a fair amount of low-hanging fruit. I am possibly stuck on two issues, but I plug away on it as I have free time. The hardest part is finding the actual line of code that have the bug. With my work, they are being marked which makes future work easier. I did see code that is possibly problematic in places like DecoView but I'm just focusing on the visible ones. Toolbar bitmaps are the most important. The Sidebar is the most broken. Do you think they will fix it? Anyway, I look forward to working through the issues soon because I have some time now and hopefully getting this into 4.2. -Keith Great work. But IMHO this doesn't really solve the problem - or at least I think this approach is not correct for canvas elements like wave lines. Everything drawn on canvas
Font style and size dropdown widths
One thing I'm looking at right now is changing the font style and size
dropdown width. With Gnome 3.10 out of the box, I can fit 7 digits into the
size box ;-) The font style dropdown also feels a bit too big. So I trimmed
25% off the style name and 33% from the font size which still leaves plenty
of room. I didn't consider to change the font name because it seems fine
and they are often longer than style names.
The first change is in a .src file so I can't do any special logic coding
and it doesn't seem like it should be necessary with APPFONT dimensions.
Would it be okay if we trimmed those values somewhat? I haven't looked yet
if logical dimensions are based on dpi or font size so maybe that should be
changed. My fixes can mostly be proven to not break the standard-res
behavior, but these two can't, And they might not necessarily look good on
Macs or various other scripts either.
Thanks!
-Keith
diff --git a/svx/source/tbxctrls/tbcontrl.src
b/svx/source/tbxctrls/tbcontrl.src
index 4d2cfbc..665f0fa 100644
--- a/svx/source/tbxctrls/tbcontrl.src
+++ b/svx/source/tbxctrls/tbcontrl.src
@@ -74,7 +74,7 @@ String RID_SVXSTR_FRAME_COLOR
ComboBox RID_SVXTBX_STYLE
{
HelpId = HID_STYLE_LISTBOX ;
-Size = MAP_APPFONT ( 67 , 86 ) ;
+Size = MAP_APPFONT ( 50 , 86 ) ;
DropDown = TRUE ;
Sort = TRUE ;
AutoHScroll = TRUE ;
diff --git a/svx/source/tbxctrls/tbunocontroller.cxx
b/svx/source/tbxctrls/tbunocontroller.cxx
index 36e257e..c343844 100644
--- a/svx/source/tbxctrls/tbunocontroller.cxx
+++ b/svx/source/tbxctrls/tbunocontroller.cxx
@@ -85,7 +85,7 @@ SvxFontSizeBox_Impl::SvxFontSizeBox_Impl(
FontSizeBox( _pParent, WinBits( WB_DROPDOWN ) ),
m_pCtrl ( _rCtrl ),
-m_aLogicalSize ( 30,100 ),
+m_aLogicalSize ( 20,100 ),
m_bRelease ( true ),
m_xDispatchProvider ( _rDispatchProvider ),
m_xFrame( _xFrame )
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: HiDPI Wiki page
I just found the font color, etc. dropdown triangle. It was in the toolbar code and I had been looking in the combo-box, spinfield, ilstbox, etc., etc. I had given up and started looking at the more toolbar buttons indicator, and that triangle drawing routine is right below it ;-) On Tue, Dec 10, 2013 at 8:00 PM, Keith Curtis keit...@gmail.com wrote: Here is a wiki page to track the feature work: https://wiki.documentfoundation.org/Development/HiDpi In there you can see a screenshot of the toolbar issues: https://wiki.documentfoundation.org/File:LibreOffice_HiDPI_toolbar_bugs.pdf And a list of the other issues, and a todo list of places to keep looking ;-) I've mostly fixed the status bar controls on my machine. It was primarily changing the code to not assume it knew the bitmap size, and then doing bitmap doubling. I will submit it to Gerrit when I can write the if() to know when. I'm stuck trying to find where the font color, etc. dropdown triangle is drawn on Linux. I searched for more than an hour, and tried commenting out code in DecoView, ImplButton, etc. to find the place, but no luck. Any pointers? Is there a reason why it can't use the same dropdown logic that the font size uses? It will take a while to fix every place, but I'll keep working on the most annoying ones... -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] HiDPI fixes for squiggly underlines
I wanted to follow up with the underline issue clipping code below and send
a new patch.
I have looked again at the code and did more testing. I started by
commenting out the check again and was able to see problems so I can say
that code is sometimes still important. But it doesn't appear to need a fix
for the yStart++ statement. I didn't increment the nEndY because the value
is currently unused later in the function ;-)
The maMetric.mnWUnderlineSize value is itself a calculated value that tries
to be about 1/2 the descent, and so not entirely to be trusted on how much
space is actually available. Between that logic, and the logic to shrink
the wave line at small descents, it appears fine. At the very least this
bug will only show up on HiDPI computers so that decreases the risk.
Respecting that clipping boundary by setting nStartAddditional = 1 often
makes the spelling underlines only 4 pixels tall at normal zooms with 12
point text on my screen. As I say in the comment, the check should be using
the full descent which gives it more space, but that diff is bigger.
In any case, in this new version I have put in a variable that handles that
issue if someone runs into problems. I'm happy to look at bugs but in here
I've got a fix ready to go. I could consider to fix properly for a future
version, but for now small fixes are best.
Finding the relevant code is often harder than making the fix. It is like
digging in the desert. Opengrok is invaluable. I can fix about 2 places per
session. Yesterday I wrote the code to fix the treeelistview + / - controls
only to eventually find out it was a native one that doesn't seem to allow
being drawn bigger! So I gave up on that issue. If the fix isn't relevant
to Linux, then screw it ;-) Hopefully it is native on all platforms and the
internal bitmaps, etc. can be removed.
-Keith
diff --git a/vcl/source/gdi/outdev3.cxx b/vcl/source/gdi/outdev3.cxx
index f3f5a77..c6de53f 100644
--- a/vcl/source/gdi/outdev3.cxx
+++ b/vcl/source/gdi/outdev3.cxx
@@ -5299,11 +5299,28 @@ void OutputDevice::DrawWaveLine( const Point
rStartPos, const Point rEndPos,
}
long nWaveHeight;
+long nStartAdditional = 0;
+
if ( nStyle == WAVE_NORMAL )
{
nWaveHeight = 3;
nStartY++;
nEndY++;
+
+if (1) //hidpi
+{
+nWaveHeight = 5;
+nStartY++; //Shift down an additional pixel for hidpi screens.
+ //TODO: Probably should be done above, before the
rotation happens
+
+//Shifting down an additional pixel could cause problems
because the #109280# code below
+//doesn't know. However, the value itself is about half the
descent and so we do have more
+//space than we think.
+//Furthermore, when I did enable nStartAdditional = 1, then
the lines LibreOffice
+//drew were very frequently just 4 pixels at normal zooms and
don't look as good. If that pixel causes
+//repaint problems, set this value to 1 and consider to
revisit the below check to do something
+//based on descent which is a better measure of space
available. Why LO isn't already doing that is beyond me.
+nStartAdditional = 0; //Set to 1 if HiDPI redraw problems.
+}
}
else if( nStyle == WAVE_SMALL )
{
@@ -5316,11 +5333,11 @@ void OutputDevice::DrawWaveLine( const Point
rStartPos, const Point rEndPos,
// #109280# make sure the waveline does not exceed the descent to
avoid paint problems
ImplFontEntry* pFontEntry = mpFontEntry;
- if( nWaveHeight pFontEntry-maMetric.mnWUnderlineSize )
- nWaveHeight = pFontEntry-maMetric.mnWUnderlineSize;
+ if( nWaveHeight + nStartAdditional
pFontEntry-maMetric.mnWUnderlineSize )
+ nWaveHeight = pFontEntry-maMetric.mnWUnderlineSize -
nStartAdditional;
ImplDrawWaveLine( nStartX, nStartY, 0, 0,
- nEndX-nStartX, nWaveHeight, 1,
+ nEndX-nStartX, nWaveHeight, 2,
nOrientation, GetLineColor() );
if( mpAlphaVDev )
mpAlphaVDev-DrawWaveLine( rStartPos, rEndPos, nStyle );
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
HiDPI Wiki page
Here is a wiki page to track the feature work: https://wiki.documentfoundation.org/Development/HiDpi In there you can see a screenshot of the toolbar issues: https://wiki.documentfoundation.org/File:LibreOffice_HiDPI_toolbar_bugs.pdf And a list of the other issues, and a todo list of places to keep looking ;-) I've mostly fixed the status bar controls on my machine. It was primarily changing the code to not assume it knew the bitmap size, and then doing bitmap doubling. I will submit it to Gerrit when I can write the if() to know when. I'm stuck trying to find where the font color, etc. dropdown triangle is drawn on Linux. I searched for more than an hour, and tried commenting out code in DecoView, ImplButton, etc. to find the place, but no luck. Any pointers? Is there a reason why it can't use the same dropdown logic that the font size uses? It will take a while to fix every place, but I'll keep working on the most annoying ones... -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [tdf-discuss] macro compatibility between LO and AOO?
On Mon, Mar 4, 2013 at 1:46 AM, Fernand Vanrie s...@pmgroup.be wrote: On 4/03/2013 8:27, M. Fioretti wrote: On Mon, Mar 04, 2013 08:16:25 AM +0100, Fernand Vanrie wrote: 99% percent , changes comes and will come from incompatiliteis in de API. for now this is OK, small changes from version to version, but nothing who not can been repaired or handled with the code( basic) itself I knew that. The sense of my question is, is there is a list of things to avoid beforehand, rather than wait that they break and fix the code? thats more a question for the developers list . LibreOffice@lists.freedesktop.org and fore the aOO counterpart ooo-...@incubator.apache.org Thanks, Marco The reason why nobody responded is no one knows, and it will generally get worse over time as the codebases diverge. It is sort of like the Java: write once, test everywhere situation. One of the unintended consequences of the fork is the various ways it makes things more difficult for third-parties. Users will generally pick one product, but extension developers have a more complicated set of choices because they may want to support multiple brands. Here is an article I recently wrote about the power of brands that may be helpful: http://keithcu.com/wordpress/?p=3163 The good news is that in the free software world, code flows with less friction. Any typical (non-enterprise) who really wants an extension will likely be able to install a specific version of the product if it is required. It is just a download. Good luck! Regards, -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
