Re: [Libreoffice] [PATCH] CppCheck cleanliness in bootstrap
On Tue, Jan 04, 2011 at 10:41:26PM +0100, Guillaume Poussel wrote: Hi everybody, I've started to look at the huge listhttp://libreoffice.boldandbusted.com/of defects that Cpp Check show. I have corrected few things in bootstrap. The rest should be false positive or errors in dmake/ folder. It would be great if someone could have a look and keep me posted about this. Regards! Thanks, pushed. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] CppCheck cleanliness in bootstrap
On Wed, Jan 05, 2011 at 09:10:51AM +0100, David Tardon wrote: On Tue, Jan 04, 2011 at 10:41:26PM +0100, Guillaume Poussel wrote: Hi everybody, I've started to look at the huge listhttp://libreoffice.boldandbusted.com/of defects that Cpp Check show. I have corrected few things in bootstrap. The rest should be false positive or errors in dmake/ folder. It would be great if someone could have a look and keep me posted about this. Regards! Thanks, pushed. Pushed, I said! D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] Formula cursor proposals
On 04/01/11 23:43, Christoph Noack wrote: The main issue is, that we do have two different input methods (one being WYSIWYG, the other one being the formula syntax) that have to be synced somehow. The content itself isn't the main problem, but things like cursor position and selection. We can only have one, because this corresponds with the current focus that is visualized for the user. So here is some initial idea that might serve as some input to solve that issue. It already implies some step-by-step approach to achieve reasonable maturity: Diving in as usual (and possibly missing the point.. :-) Have you played with WordPerfect which - iiuc - has EXACTLY this issue syncing the wysiwyg and reveal-codes windows. A mouse click in the wysiwyg window places the cursor at that point and makes that the active window. A mouse click in the rc window places the mouse cursor at that point and makes that the active window. Bear in mind the rc window has extra characters, ie the formatting codes. If the rc window is active the cursor keys move in that window, updating the wysiwyg window if appropriate. If wysiwyg is active, the cursor keys move in that window, jumping multiple characters in rc if appropriate. This obviously all depends on the two windows being able to update each other in sync (I gather that would be a nightmare in Writer :-(, but if it's possible, then imho that would be the perfect way to do it - the mouse swaps focus between windows - the active window eats and processes the keyboard - and the inactive window is updated in real time by the active one. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Test script patch review request (1)
Would you also like to comment my updated method sent yesterday? Thanks! Well, it was not clear to me why you want to expand only initial tabs. Presumably when somebody uses tab characters in a source file, they intend them to tab to the next multiple of four columns regardless where on the line they are? That is how the editor shows the source files to the person editing it. Or am I missing something? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Linux] LibORC2: Impress video / `GLIBCXX_3.4.11' not found
Hi, NoOp píše v Út 04. 01. 2011 v 20:42 -0800: Can LibORC3 include an updated libstdc++.so.6 so that others do not have the same issue? Thanks. No response on the list. Would it help if I filed a bug report, or are LibO devs already aware of the issue? IMO this would be a blocking bug as former OOo users w/go-oo patches et al are expecting to include proper videos in Impress. Yes, please do. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] unopkg --suppress-license
Hello Kohei, others, I have created a bug report for this (fdo#32840)... and fixed it in master branch. Could someone review it for a possible integration in 3.3 ? Regards, -- Cedric On Tue, 2011-01-04 at 16:09 -0500, Kohei Yoshida wrote: On Tue, 2011-01-04 at 22:04 +0100, Cedric Bosdonnat wrote: Hello hackers, I would like to make the --suppress-license option of unopkg skip the license in all cases instead of depending on what is in the extension's description.xml //simple-licen...@suppress-if-required]. http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements#Element_.2Fdescription.2Fregistration.2Fsimple-license According to this wiki page, this feature has been introduced in OOo 3.3... which isn't released yet. Do you have any strong opinion against that? I would need this kind of unconditional skip to run unopkg from within ooeclipse... where people should develop their extensions and know the license ;) IMO the principle of lease surprise dictates that, when given --suppress-license, it should suppress license unconditionally no matter what some file in undisclosed location has in it. So, I'm with you on that. Kohei -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Linux] LibORC2: Impress video / `GLIBCXX_3.4.11' not found
Hi there, On Fri, 2010-12-31 at 11:23 -0800, NoOp wrote: (soffice:22820): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /opt/libreoffice/program/../basis-link/ure-link/lib/libstdc++.so.6: Gack; another instance of our internal libstdc++ biting us hard. I wonder if using RTLD_DEEPBIND on this sort of component's dlopen might help us; hmm. If I: $ sudo cp /usr/lib/libstdc++.so.6 /opt/libreoffice3/ure/lib/ and $ sudo cp /usr/lib/libstdc++.so.6 /opt/libreoffice/ure/lib/ the video now runs without issue. It's a great bug report - thanks; as Kendy says having it in bugzilla would help. The hope is that vendors will use their native libstdc++ - so this affects only the generic builds. Can LibORC3 include an updated libstdc++.so.6 so that others do not have the same issue? Thanks. That might be a temporary solution too, Hmm, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Sign-off request
Hi Kohei, On Tue, 2011-01-04 at 16:06 -0500, Kohei Yoshida wrote: Could someone please give me a quick sign-off of this Done - looks great :-) Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Removed dependencies on tools/solar.h in waitoff.h
Hi Soeren, Soeren Moeller píše v Út 04. 01. 2011 v 19:48 +0100: Another small removal of dependencies on tools/solar.h, this time in sc/inc/waitoff.h Pushed, thank you! :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Change executable/sh names
On Wed, Jan 5, 2011 at 5:38 AM, NoOp gl...@sbcglobal.net wrote: On 12/24/2010 03:26 PM, NoOp wrote: On 12/24/2010 11:32 AM, Jesús Corrius wrote: ... I see, I was able to reproduce it after making a few tests. Let me investigate this further. Scenarios that work (for me) - OpenOffice 3.3 RC8 + LibO 3.3 RC2 = Works OpenOffice 3.2.1 final + LibO 3.3 RC2 = Works Scenarios that don't work (for me) Microsoft Office 2007 + OpenOffice 3.2.1 final + LibO 3.3 RC2 = Doesn't work Microsoft Office 2007 + LibO 3.3 RC2 + OpenOffice 3.2.1 final = Doesn't work Microsoft Office 2007 + LibO 3.3 RC2 + OpenOffice 3.3 RC8 = Doesn't work Microsoft Office 2007 + OpenOffice 3.3 RC8 + LibO 3.3 RC2 = Doesn't work LibO 3.3 RC2 + OpenOffice 3.2.1 final = Doesn't work LibO 3.3 RC2 + OpenOffice 3.3 RC8 = Doesn't work Thanks! Any progress on this? Would it help if I filed a bug report? This issue is (to me) critical regarding any further RC or full release of LibO. Sorry, I have been in Norway for more than week in a cabin without computers or internet connection. I will send a patch very soon. Cheers, -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Remove DECLARE_LIST( EditList, AppWIn*)
Hi Joseph
On -10/01/37 20:59, Joseph Powers wrote:
The attached patch compiles and stands up to my limited testing; however, it's a
large patch and touches a lot of sensitive code so I want someone with better
knowledge of the Basic Macro Editor environment to review test it before I
try pushing it.
Thanks,
Joe P.
I wouldn't claim to have much knowledge of the Basic Macro editor but I
suppose at least I have touched it in the past ;-)
Firstly congratulations on this is great work, getting rid of those
horrific macro lists and replacing with something more modern surely
will make things easier for new developers to understand. As far as I
can see the changes as they stand shouldn't cause any problems and could
be committed.
My only comment would be that mostly the opportunity to simplify the
code using the power of the vector has not being taken advantage of
which is a pity ( and would be great to fix here ) e.g.
@@ -627,17 +627,15 @@ void BasicFrame::LoadIniFile()
if ( pBasic )
pBasic-LoadIniFile();
-for ( i = 0 ; i pList-Count() ; i++ )
-pList-GetObject( i )-LoadIniFile();
+for ( i = 0 ; i pList-size() ; i++ )
+pList-at( i )-LoadIniFile();
}
could be much clearly expressed using iterators ( and no need to check
the size every loop iteration either )
e.g. something like
EditList::iterator it = pList-end()
for ( EditList::iterator it = pList-begin(); it != it_end; ++it )
*it-LoadIniFile();
similarly really ugly index manipulation e.g.
@@ -777,11 +775,10 @@ void BasicFrame::Resize()
// Resize possibly maximized window
-ULONG i;
-for( i = pList-Count(); i 0 ; i-- )
+for( size_t i = pList-size(); i 0 ; i-- )
{
-if ( pList-GetObject( i-1 )-GetWinState() == TT_WIN_STATE_MAX )
-pList-GetObject( i-1 )-Maximize();
+if ( pList-at( i-1 )-GetWinState() == TT_WIN_STATE_MAX )
+pList-at( i-1 )-Maximize();
}
}
could be simplified and avoided by again making use of the power of the
vector
EditList::iterator::reverse_iterator rit_end = pList-rend();
for ( EditList::iterator::reverse_iterator rit=pList-rbegin() ;
rit != rit_end; ++rit )
{
if ( *rit-GetWinState() == TT_WIN_STATE_MAX )
*rit-Maximize();
}
nearly all of the hunks in the patch could be modified similarly I think.
note: my crappy pseudo code bits above are not compiled or tested but
you get what I mean I am sure
thanks again
Noel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] new cppcheck cleaning in svx
Hi Julien,
thanks for your patches. They look OK so I pushed them.
Cheers
Radek
On Thu, 2010-12-30 at 00:51 +0100, Julien Nabet wrote:
Hello,
Here are 2 new patches for cppcheck cleaning in svx
Compiling was ok
Remarks :
I had this with the last git version of cppcheck :
1)
[./svdotxln.cxx:67]: (style) The class 'ImpSdrObjTextLink' does not have
a constructor.
but we can read this on the file :
class ImpSdrObjTextLink: public ::sfx2::SvBaseLink
{
SdrTextObj* pSdrObj;
public:
ImpSdrObjTextLink( SdrTextObj* pObj1 )
: ::sfx2::SvBaseLink( ::sfx2::LINKUPDATE_ONCALL, FORMAT_FILE ),
pSdrObj( pObj1 )
{}
...
It seems there is a constructor, doesn't it ? So either if it's a false
positive and i do a tracker or it's ok and i would need some explanation
(please ! :-) ).
2)
in view3d.cxx, I've got this :
[./view3d.cxx:299]: (style) Variable 'pM' is assigned a value that is
never used
but either pM should be used (and i don't know how) or pM is useless and
this entire line too :
pM = GetSdrMarkByIndex(nObjs);
3)
Checking ./gridctrl.cxx...
[./gridctrl.cxx:3720]: (error) Possible null pointer dereference:
pListeners - otherwise it is redundant to check if pListeners is null at
line 3722
but I don't know what to do with this.
There are still some cppcheck in svx, i hope to correct all of them soon.
Julien
(LGPLv3+ / MPL)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi Jean, On Wed, 2010-12-29 at 21:11 +0100, Jean-Baptiste Faure wrote: Jonas wrote: Assuming someone cares to implement it... and you're are welcome to step up to the plate :) .. I strongly disagree : it is you who must not to destroy what is working very well. Jean - this sort of adjective destroy, is a shame to apply to some wonderful work that will really help millions to edit formulae in a more simple and effective way - for which we should be extremely grateful to Jonas. It distresses me to see developers criticised for introducing some minor bug or regression along with a huge improvement: which this work is (even if you don't appreciate the added function) :-) The programming problem of fixing the cursor / selection is not a very difficult one - however, if we apply (perhaps accidentally) harsh words to the problem instead of encouraging and trying to help out: filing bugs / updating the easy hacks wiki etc. as suggested: there is a danger that we end up with no developer volunteers :-) Anyhow - it seems like this change should be tractible even to a very beginner coder; do you have a build you can play with - and perhaps you can help be part of the solution ? :-) I can give you some code pointers - indeed, I thought that I had addressed an issue like this as/when I merged this. Grab me (mmeeks) on IRC and I'll help you get setup. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Patch] Make SVG filter export text color
Hi Takeshi, On Tue, 2011-01-04 at 14:30 +0900, KUROSAWA, Takeshi wrote: I wrote patches for SVG export filter. Nice ! :-) thes look great. Having said that - I suggest we wait for Thorsten to review them (who gets back from holiday tommorrow). Is that ok ? Really great to have you involved :-) Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Horizontal glyph adjustments are ignored with ICU layout
Hi every one,
This my first message to the list, hopping it will be a fruitful
experience :)
I was trying to debug fdo#31016[1] since it breaks almost all my fonts,
it toke me few months but I think I finally got the root of it (I
started working on it few weeks before libreoffice was announced, what a
nice code base ;).
Anyway, it turned out that the issue is not specific to kerning nor
Arabic, but affects all horizontal glyph positioning in the ICU layout
path; the problem does not show on Windows nor with Graphite fonts and
of course not with con-CTL.
The X adjustment of glyph widths is simply ignored, and glyphs are drawn
stacked after each other baased on their original width, which results in
kerning being ignored as well as other forms of glyph positioning like
cursive anchors, however vertical glyph positions (in the Y access) are
OK.
In source/glyphs/gcach_layout.cxx, ICU's layoutChars() is called and new
glyph indices and positions are returned, which is then fed into
SalLayout in the form of GlyphItem's. Though GlyphItem has maLinearPos
which holds its absolute position, many places in the code re-calculate
glyph position from its mnOrigWidth (original glyph width) and mnNewWidth
(width after adjustments), but the ICU path simply sets mnNewWidth to
mnOrigWidth since ICU layout engine does not return individual glyph
widths, resulting in failure of glyph position re-calculation which
manifests in this bug.
As a prove of concept, the attached patch trays to set mnNewWidth in a
very hackish way by subtracting current glyph position from the of next
non-diacritic (+ve) glyph. It does indeed fix the problem (see the
attached screenshots), but it looks very unreliable to me. May be a
cleaner solution is to re-implement all the broken virtual methods to
eliminate the re-calculation part.
Hope this helps, and sorry for the broken terminology as I'm not really
a developer and less of C++ one (I can only do much of C++ that looks
like C, which I don't really speak either).
[1] https://bugs.freedesktop.org/show_bug.cgi?id=31016
Regards,
Khaled
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
diff --git a/vcl/source/glyphs/gcach_layout.cxx b/vcl/source/glyphs/gcach_layout.cxx
index cda8749..7531d2b 100644
--- a/vcl/source/glyphs/gcach_layout.cxx
+++ b/vcl/source/glyphs/gcach_layout.cxx
@@ -534,12 +534,35 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
aNewPos = Point( (int)(pPos-fX+0.5), (int)(pPos-fY+0.5) );
const GlyphMetric rGM = rFont.GetGlyphMetric( nGlyphIndex );
int nGlyphWidth = rGM.GetCharWidth();
+int nNewWidth = nGlyphWidth;
if( nGlyphWidth = 0 )
bDiacritic |= true;
// #i99367# force all diacritics to zero width
// TODO: we need mnOrigWidth/mnLogicWidth/mnNewWidth
-else if( bDiacritic )
-nGlyphWidth = 0;
+else {
+if( bDiacritic ) {
+nGlyphWidth = 0;
+nNewWidth = 0;
+} else {
+// Hack, find next +ve width glyph and calculate current
+// glyph width by substracting the two posituons
+const IcuPosition* pNextPos = pPos+1;
+for ( int j = i + 1; j nRawRunGlyphCount; ++j, ++pNextPos) {
+LEGlyphID nNextGlyphIndex = pIcuGlyphs[j];
+
+if( (nNextGlyphIndex == ICU_MARKED_GLYPH) || (nNextGlyphIndex == ICU_DELETED_GLYPH) )
+continue;
+
+const GlyphMetric rNextGM = rFont.GetGlyphMetric( nNextGlyphIndex );
+int nNextGlyphWidth = rNextGM.GetCharWidth();
+
+if (nNextGlyphWidth0) {
+nNewWidth = pNextPos-fX - pPos-fX;
+break;
+}
+}
+}
+}
// heuristic to detect glyph clusters
bool bInCluster = true;
@@ -593,7 +616,9 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
nGlyphFlags |= GlyphItem::IS_DIACRITIC;
// add resulting glyph item to layout
-const GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+aGI.mnNewWidth = nNewWidth;
+//printf(%ld: %d=%d\n, aGI.mnGlyphIndex, aGI.mnOrigWidth, aGI.mnNewWidth);
rLayout.AppendGlyph( aGI );
++nFilteredRunGlyphCount;
nLastCharPos = nCharPos;
attachment: before.pngattachment: after.png___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Robert, On Mon, 2011-01-03 at 02:16 +0100, Christian Lohmaier wrote: - aStyleSet.SetToolbarIconSize( STYLE_TOOLBAR_ICONSIZE_LARGE ); +aStyleSet.SetToolbarIconSize( nDispDPIY 160 ? STYLE_TOOLBAR_ICONSIZE_LARGE : STYLE_TOOLBAR_ICONSIZE_SMALL ); On large numbers of machines, nDispDPI is just broken - it is fetched (AFAIR) from Xft - and is ~hard-coded to 75 everywhere to save lots of grief from X servers getting it horribly wrong. So - the net effect of this is to simply default to tiny icons, even on huge screens. How much effort would it be to read the property from gconf if available (or is this already done when DESKTOP=gnome)? That shouldn't be necessary - I believe we shoudl sync the Xft setting; but perhaps there is some xsettings linkage we could add: gtk-xft-dpi or somesuch. I prefer small icons, no matter what. Icons are there to preserve space, provide access to functionality, not to waste my screen-estate with pretty pictures. Sure - but you know what the icons do :-) and you are expert with the keybindings. Of course - if you are an expert, you can turn the icons to a smaller size too ;-) Personally, my emacs has no toolbar, or menu bar but ... this is not a good default. So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? ATB, Michael. That would work fine too, I am all for it. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] visual formula editor makes unwanted changes to command line
On Sun, 2011-01-02 at 21:12 +0100, Jonas Finnemann Jensen wrote: I have installed RC2 now, but I see no difference in formula editor. I don't think everything from master is merged into the release candidate... And since this is still an experimental feature we're slow at pushed things out... Right :-) best to test this on master; hopefully when turned off it doesn't cause too much grief, and this is getting us some useful bug / testing feedback :-) If the feature were more clearly separated I'd suggest we back-port fixes more aggressively to the stable branch (since it is clearly flagged as experimental). Having said that - if we have any fixes for regressions that are not working when the feature is not enabled - we should back-port them: are there any ? Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Removed dependencies on tools/solar.h in drawpage.hxx/.cxx
Hi Soeren, Sören Möller píše v Út 04. 01. 2011 v 20:20 +0100: Replaced datatypes from tools/solar.h with corresponding types from sal/types.h in drawpage.hxx/.cxx and added missing include of sal/types.h in docparam.hxx Pushed, thank you! :-) I've just changed one thing, and that is that I used the 'bool' type instead of sal_Bool; sal_Bool should be used only when it comes to UNO, and bool is preferred otherwise. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Meeks, Robert, 2011-01-05 15:27 keltezéssel, Michael Meeks írta: Hi Robert, On large numbers of machines, nDispDPI is just broken - it is fetched (AFAIR) from Xft - and is ~hard-coded to 75 everywhere to save lots of grief from X servers getting it horribly wrong. So - the net effect of this is to simply default to tiny icons, even on huge screens. Good to know :oD Thanks! I prefer small icons, no matter what. Icons are there to preserve space, provide access to functionality, not to waste my screen-estate with pretty pictures. Sure - but you know what the icons do :-) and you are expert with the keybindings. Of course - if you are an expert, you can turn the icons to a smaller size too ;-) Personally, my emacs has no toolbar, or menu bar but ... this is not a good default. ;o) So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? So I am with Robert, I prefer small icons. I using this settings in my laptop (1440x900) and icons are recognisable easily (I prefer Galaxy (original set) over others). Why do we force big icons? Is it a customer request, or UX decision? I am using 22 monitor and 1920x1080 is comfortable for me with small icons. ATB, Michael. -- Best regards, Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com My favorite projects: OxygenOffice Professional http://ooop.sf.net/ - office suite - for everybody | Magyarul http://hun.sf.net/ - In Hungarian Blog http://bit.ly/10ucTR | Support http://bit.ly/eYZO6 Follow me http://bit.ly/gJuJZ, if you can http://bit.ly/kDocB signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h in drawpage.hxx/.cxx
Hi Sören,
Thanks for the patch. Is there a reason why this one is not an
attachment? :-)
Anyway, I have some comments.
On Tue, 2011-01-04 at 20:20 +0100, Sören Möller wrote:
Replaced datatypes from tools/solar.h with corresponding types from
sal/types.h in drawpage.hxx/.cxx and added missing include of sal/types.h in
docparam.hxx
---
sc/inc/docparam.hxx |1 +
sc/inc/drawpage.hxx |4 ++--
sc/source/core/data/drawpage.cxx |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/sc/inc/docparam.hxx b/sc/inc/docparam.hxx
index 2511f26..01170a5 100644
--- a/sc/inc/docparam.hxx
+++ b/sc/inc/docparam.hxx
@@ -32,6 +32,7 @@
#ifndef SC_DOCPARAM_HXX
#define SC_DOCPARAM_HXX
+#include sal/types.h
#include address.hxx
This should not be necessary (though it won't hurt) as the address.hxx
already includes sal types. Does it not build without this change for
you?
// Let's put here misc structures that get passed to ScDocument's methods.
diff --git a/sc/inc/drawpage.hxx b/sc/inc/drawpage.hxx
index faa43fa..5e207b7 100644
--- a/sc/inc/drawpage.hxx
+++ b/sc/inc/drawpage.hxx
@@ -30,7 +30,7 @@
#define SC_DRAWPAGE_HXX
#include svx/fmpage.hxx
-
+#include sal/types.h
class ScDrawLayer;
@@ -39,7 +39,7 @@ class ScDrawLayer;
class ScDrawPage: public FmFormPage
{
public:
-ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, BOOL
bMasterPage=FALSE);
+ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, sal_Bool
bMasterPage=sal_False);
~ScDrawPage();
virtual ::com::sun::star::uno::Reference
::com::sun::star::uno::XInterface createUnoPage();
diff --git a/sc/source/core/data/drawpage.cxx
b/sc/source/core/data/drawpage.cxx
index d489d5d..5a91540 100644
--- a/sc/source/core/data/drawpage.cxx
+++ b/sc/source/core/data/drawpage.cxx
@@ -44,7 +44,7 @@
// ---
-ScDrawPage::ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, BOOL
bMasterPage) :
+ScDrawPage::ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, sal_Bool
bMasterPage) :
FmFormPage(rNewModel, pBasic, bMasterPage)
{
SetSize( Size( LONG_MAX, LONG_MAX ) );
For these two, let's use the standard bool type. In fact, its parent
class FmFormPage does expect a parameter of the bool type, not sal_Bool
nor BOOL (though the default value is for some reason set to sal_False
instead of false, which should really be fixed...), which provides
another reason to use bool, not sal_Bool.
Thanks!
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? Oh wait, I misunderstood. That is wrong. I am on a 1920x1080 display and i still prefer the small icons, it is like that in _every_ app. So we should stick to the DPI. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] De-Java-ise flat XML export
Hi Peter,
Jan Holesovsky píše v Út 04. 01. 2011 v 11:13 +0100:
I'm attaching a patch I somehow managed to patiently pull out of git :-)
As I'm new to C++, libxslt, git and a few other things involved in
creating the patch I feel it must be full of warts and cause random
crashes, but it seems to work and might be useful anyway.
Thanks a lot - looks great on the first sight :-) Let me look a bit
better (unless somebody else volunteers to do a deeper review?) now.
Before pushing it to the master branch, I'd like to ask you for 2
things:
License: Please, do you agree to license under the MPL / LGPL / GPL
combo, as recommended in
http://cgit.freedesktop.org/libreoffice/build/tree/COPYING.NEWFILES
Purpose documentation: Can you please add a brief description of the new
classes in the header? Just something like:
I looked mainly at the parts that are about defaulting to your
implementation, or the Java xslt filter, and it looks good to me, so I'd
push it as soon as you let us know regarding the license :-)
One more nitpick that I spotted is that you use { and } differently to
the rest of the code base (we use opening { on a new line, and skip
{ and } if an if/for/while has only one command), would be great if you
can change it too; but of course that is not a blocker for pushing your
changes ;-)
Also, is there a special reason for ListenerList l = m_listeners; on few
occasions? Didn't you want to use a reference?
Thank you a lot,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] BrOffice RC2
Hi Michael, 2011/1/5 Michael Meeks michael.me...@novell.com No problem; there is one known branding bug inside the MSI, that we need to work around before release. Have you also solved https://bugs.freedesktop.org/show_bug.cgi?id=32389 (MSI installer is always in English regardless of regional settings in Windows)? Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Updating to latest git source code
Hi, Could somebody tell me how to update to the latest git release? There used to be a bin/g scvript that did that but it's gone. Thanks, -- Grega Fajdiga Hacquetova 5 1113 Ljubljana Slovenia GSM: +386 40 923 635 E-pošta: gregor.fajd...@guest.arnes.si ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Translated comments from German to English
On Tue, 2011-01-04 at 22:26 +0100, Christina Roßmanith wrote: ...some more translations. Nice work! Pushed. -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Updates for Lightproof
Hi Kami, On Wed, 2010-12-22 at 18:28 +0100, Kálmán „KAMI” Szalai wrote: Please review the attached patch that provide updated support for Ligthproof extension integration for 3.3.x series. Looks lovely :-) but can we punt this for 3.3.1 ? I think we need to be getting into some really deep code freeze for 3.3.0 just now - I hope to have a final release / GMC of that in the next week or so. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Oracle wordbook in LibO
Kálmán „KAMI” Szalai píše v Pá 31. 12. 2010 v 10:17 +0100: Hi All, Patches attached to issue, please review. Ah, we use Novell.dic in our build. It includes just language-independent names of Novell products, so it should not cause any harm to anyone. I attached different patches to the issue. KAMI, could you please review them? I also found that: * We don't provide standard.dic as user dictionary. Is this intentional? It looks fine. It is empty by default. It is automatically created when user add his own words in the spellcheck dialog. * We provide language dependent *.dic files in binary format, however standard.dic is a plain text file. Heh, I wonder how the binary dictionaries were created. I guess that it is an older format that comes from the old StarOffice times. I suggest to create any new dictionary in the text format. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix-font-assignation-of-extra-fonts
Hi Kami, On Wed, 2010-12-22 at 18:22 +0100, Kálmán „KAMI” Szalai wrote: Sorry, my mistake. Attached. You sure these need review ? :-) your work looks nice - and no doubt it can be tweaked later if there are problems ? :-) /me feels bad about leaving this un-reviewed so long. ATB, Michael. PS. we have all those font's licenses in the license files right ? -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updating to latest git source code
type ./g pull -r in the boot strap directory let me know if it works. On 1/5/11 2:40 PM, Grega Fajdiga wrote: Hi, Could somebody tell me how to update to the latest git release? There used to be a bin/g scvript that did that but it's gone. Thanks, ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Pushed] Refreshing some OxygenOffice related patches
Hi Kami, On Thu, 2010-12-30 at 08:17 +0100, Kálmán „KAMI” Szalai wrote: I attaching two patch that: * refreshing some OxygenOffice related patches * disable few OxygenOffice only patches from apply file Look fine to me for libreoffice-3-3; they only touch Oxygen pieces, pushed them :-) Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Oracle wordbook in LibO
Hi! 2011-01-05 17:01 keltezéssel, Petr Mladek írta: Ah, we use Novell.dic in our build. It includes just language-independent names of Novell products, so it should not cause any harm to anyone. I attached different patches to the issue. KAMI, could you please review them? Can we introduce here some other technical, and distibution related files here, not just Novell related, words from Ubuntu, Debian, etc. I think we should have only one extra dic file, or is is a performance killer thing? I also found that: * We don't provide standard.dic as user dictionary. Is this intentional? It looks fine. It is empty by default. It is automatically created when user add his own words in the spellcheck dialog. Ok :oD * We provide language dependent *.dic files in binary format, however standard.dic is a plain text file. Heh, I wonder how the binary dictionaries were created. I guess that it is an older format that comes from the old StarOffice times. I suggest to create any new dictionary in the text format. We should ask it on L10N list. Maybe update would be nice. Best Regards, Petr -- Best regards, Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com My favorite projects: OxygenOffice Professional http://ooop.sf.net/ - office suite - for everybody | Magyarul http://hun.sf.net/ - In Hungarian Blog http://bit.ly/10ucTR | Support http://bit.ly/eYZO6 Follow me http://bit.ly/gJuJZ, if you can http://bit.ly/kDocB signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] 13th and 14th week development summary
Hi, this time a brief summary of what happened the 13th and 14th week on LibreOffice repos and two living branches: bugfixes-master-week-51-52.txt lists all commits that reference a proper bug id (from a variety of trackers - #i... referring to the OpenOffice issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla etc) in the master branch commit-log-master-week-51-52.txt lists all relevant commits on the actual source repos in the master branch commit-log-libreoffice-3-3-week-51-52.txt, bugfixes-libreoffice-3-3-week-51-52.txt lists the same summary for the libreoffice-3-3 branch. Many thanks to all contributors - you make all the difference! Best Regards, Petr + build: + fdo#32380, n#649506: Fixed navigation buttons' patch selection handling [Cédric Bosdonnat] + calc: + Avoid double-paste when pasting text into cell comment. (fdo#32572) [Kohei Yoshida] + Remove bogus check for numerical sheet names. (fdo#32570) [Kohei Yoshida] + extensions: + Enabling l10n of nlpsolver fdo#30839 [Andras Timar] + impress: + Resoves: rhbz#663857 font color missing; C++ FAQ 10.3 doomage (cherry picked from commit 963c6b655032b4e5d0f26555f3c26a129a9efb03) [Caolán McNamara] + libs-core: + Do not block when launching firefox, fdo#32427. [Jan Holesovsky] + Resolves: rhbz#666216 survive missing window (cherry picked from commit e9438320b50e647f6c5bf052148bcd501b7b55d4) [Caolán McNamara] + libs-gui: + If the language is not specified, use the initial language. (fdo#32523) [Kohei Yoshida] + l10n: + F~ormel menu instead of Formel - fdo#32584 [Andras Timar] + writer: + Resolves: rhbz#660342 Undo/Redo crash with postits (cherry picked from commit 1b58066892daa9365d23b39d7439fbbe7d562b13) [Caolán McNamara] + common: + Drop msvc*7*.dll, see fdo#32426 [Tor Lillqvist] + bootstrap: + Drop msvcr71, see fdo#32426 [Tor Lillqvist] + Drop msvc*7*.dll, see fdo#32426 [Tor Lillqvist] + Resolves: fdo#32426 first cut at auto-downloading windows depends [Caolán McNamara] + calc: + Avoid double-paste when pasting text into cell comment. (fdo#32572) [Kohei Yoshida] + Remove bogus check for numerical sheet names. (fdo#32570) [Kohei Yoshida] + extensions: + Enabling l10n of nlpsolver fdo#30839 [Andras Timar] + filters: + #i101360# use xsl:element for element construction [David Tardon] + impress: + Resoves: rhbz#663857 font color missing; C++ FAQ 10.3 doomage (cherry picked from commit 963c6b655032b4e5d0f26555f3c26a129a9efb03) [Caolán McNamara] + libs-core: + Allow tear-off for the Arrowheads dialog, fdo#32676. [Jan Holesovsky] + Do not block when launching firefox, fdo#32427. [Jan Holesovsky] + Rename .uno:UndoAction/Redo to Undo/Redo, fdo#32472. [Jan Holesovsky] + Resolves: rhbz#666216 survive missing window [Caolán McNamara] + Resolves: rhbz#666216 survive missing window (cherry picked from commit e9438320b50e647f6c5bf052148bcd501b7b55d4) [Caolán McNamara] + libs-extern: + Drop msvc*7*.dll, see fdo#32426 [Tor Lillqvist] + libs-gui: + gtk: Use the right padding in the menus, bnc#304620 [Jan Holesovsky] + If the language is not specified, use the initial language. (fdo#32523) [Kohei Yoshida] + Resolves: #i76587# DEFAULT encodings can't be assumed to be system encoding [Caolán McNamara] + l10n: + F~ormel menu instead of Formel - fdo#32584 [Andras Timar] + ure: + Load msvcr71.dll needed by JVM using explicit path, see fdo#32426 [Tor Lillqvist] + writer: + remove non-functional column count limit (part of fdo#30860) [Luboš Luňák] + Resolves: fdo#32633 rearrange title dialog to get translations to fix [Caolán McNamara] + Resolves: #i113655# rhbz#621277 crash with missing DocShell [Caolán McNamara] + Resolves: rhbz#660342 Undo/Redo crash with postits [Caolán McNamara] + Resolves: rhbz#660342 Undo/Redo crash with postits (cherry picked from commit 1b58066892daa9365d23b39d7439fbbe7d562b13) [Caolán McNamara] + work around tables with many columns for msoffice (fdo#30860) [Luboš Luňák] + common: + Remove extensions' filename version during unpack [Kalman Szalai - KAMI] + bootstrap: + Remove version info from extension folder name too. [Kalman Szalai - KAMI] + typo fix in helppack.ulf [Andras Timar] + Update SUN Template Pack extensions' packaing mechanism [Kalman Szalai - KAMI] + build: + Correct credits url to website conventions (again) [Andras Timar] + fdo#32380, n#649506: Fixed navigation buttons' patch selection handling [Cédric Bosdonnat] + Hungarian (hu) translation update [Andras Timar] + po/pot update because of a typo fix in scp2 module [Andras Timar] + remove long obsolete copy of (and broken check for) mysql-connector-cpp.zip [Rene Engelhard] + removing fixes-br.sdf, I merged it into the big localize.sdf [Andras Timar] + Slovenian (sl) translation update [Martin Srebotnjak] + Update patches for UbuntuMaverick and and
Re: [Libreoffice] [PATCH] Fix-font-assignation-of-extra-fonts
Hi Kami, Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 17:41 +0100: PS. we have all those font's licenses in the license files right ? Sorry I really don't know the rules for this so I just wanted to review all changes that I made after I got warned ;o) I am sorry, that is probably my mistake :-( The review/sign-off is needed for the changes to libreoffice-3-3 branch, for all the repos except 'build'. In the 'build' repo, please feel free to do whatever you need for your distro, but make sure you don't break it for the other distros, that's all. No review needed for the master branch, just the usual 'be careful enough' ;-) Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Oracle wordbook in LibO
Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 17:39 +0100: Hi! 2011-01-05 17:01 keltezéssel, Petr Mladek írta: Ah, we use Novell.dic in our build. It includes just language-independent names of Novell products, so it should not cause any harm to anyone. I attached different patches to the issue. KAMI, could you please review them? Can we introduce here some other technical, and distibution related files here, not just Novell related, words from Ubuntu, Debian, etc. I think we should have only one extra dic file, or is is a performance killer thing? Great idea! I would call it technical.dic or so. KAMI, could you please cook up something? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Oh well then Linux is broken, again. :) In gedit the icons are bigger than the small ones but not as huge as in LibreOffice. Here you can see (LO with small icons): http://blade2k.humppa.hu/2011-01-05-182917_1920x1080_scrot.png (ws robert 22435)$ xdpyinfo | egrep (dimensions|dots per inch) dimensions:1920x1080 pixels (518x291 millimeters) resolution:94x94 dots per inch It is strange for me tho that linux *hardcodes* 75. Where is taht hardcoded? On (2011-01-05 17:14), Michael Meeks wrote: Hi Robert, On Wed, 2011-01-05 at 16:24 +0100, Robert Nagy wrote: On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? Oh wait, I misunderstood. That is wrong. I am on a 1920x1080 display :-) so - as I say; the DPI is a constant of 75 across the Linux desktop, so this is not a switch but a hard coded setting :-) I am still convinced that large icons, on a reasonably sized screen give a -far- more useful view of the metaphore for a beginner user. As I say, advanced users can make it smaller. and i still prefer the small icons, it is like that in _every_ app. So we should stick to the DPI. Well; looking at gedit - it is using gtktoolbar.c's: #define DEFAULT_ICON_SIZE GTK_ICON_SIZE_LARGE_TOOLBAR ie. the same size (large) icons that we are using here. Perhaps the size setting is coming from the theme, in which case we should extract it and use exactly that setting in LibreOffice - can you have a dig ? (can you check that stock gtk+ apps do indeed have small toolbar icons ?). Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
It seems to me that gedit uses GTK_ICON_SIZE_MENU which is 16x16. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Robert, *, On Wed, Jan 5, 2011 at 6:36 PM, Robert Nagy rob...@openbsd.org wrote: It seems to me that gedit uses GTK_ICON_SIZE_MENU which is 16x16. On GNOME it follows the theme, wich in turn follows the gconf-setting /desktop/gnome/interface/toolbar_icons_size so whatever your theme defines in the gtk-icon-sizes property will be used. e.g. HighContrastLargePrint/gtk-2.0/gtkrc:gtk-icon-sizes = mini-commander-icon=24,24:print-manager=64,64:panel-button=32,32:gtk-dnd=48,48:gtk-menu=32,32:panel-menu=48,48:gtk-large-toolbar=48,48:gtk-small-toolbar=32,32:gtk-button=32,32:gtk-dialog=64,64 small-toolbar → you get 32x32 icons, large-toolbar, you get 48x48 ones. Redmond/gtk-2.0/gtkrc:gtk-icon-sizes = mini-commander-icon=32,32:print-manager=32,32:panel-button=32,32:gtk-dnd=32,32:gtk-menu=16,16:panel-menu=22,22:gtk-large-toolbar=16,16:gtk-small-toolbar=16,16:gtk-button=16,16:gtk-dialog=32,32 → small-toolbar → you get 16x15, large-toolbar → you get 16x16 as well. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PUSHED] Re: [PATCH] typo fix in helppacks.ulf
Hi Andras, Andras Timar píše v Ne 02. 01. 2011 v 14:47 +0100: same typo in module_langpack.ulf Thank you, pushed to libreoffice-3-3. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi We should just ignore all the theming here since a lot of people are not running gnome or whatever window manager and just use stock gtk. On (2011-01-05 18:59), Christian Lohmaier wrote: Hi Robert, *, On Wed, Jan 5, 2011 at 6:36 PM, Robert Nagy rob...@openbsd.org wrote: It seems to me that gedit uses GTK_ICON_SIZE_MENU which is 16x16. On GNOME it follows the theme, wich in turn follows the gconf-setting /desktop/gnome/interface/toolbar_icons_size so whatever your theme defines in the gtk-icon-sizes property will be used. e.g. HighContrastLargePrint/gtk-2.0/gtkrc:gtk-icon-sizes = mini-commander-icon=24,24:print-manager=64,64:panel-button=32,32:gtk-dnd=48,48:gtk-menu=32,32:panel-menu=48,48:gtk-large-toolbar=48,48:gtk-small-toolbar=32,32:gtk-button=32,32:gtk-dialog=64,64 small-toolbar ??? you get 32x32 icons, large-toolbar, you get 48x48 ones. Redmond/gtk-2.0/gtkrc:gtk-icon-sizes = mini-commander-icon=32,32:print-manager=32,32:panel-button=32,32:gtk-dnd=32,32:gtk-menu=16,16:panel-menu=22,22:gtk-large-toolbar=16,16:gtk-small-toolbar=16,16:gtk-button=16,16:gtk-dialog=32,32 ??? small-toolbar ??? you get 16x15, large-toolbar ??? you get 16x16 as well. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Robert, *, On Wed, Jan 5, 2011 at 7:02 PM, Robert Nagy rob...@openbsd.org wrote: We should just ignore all the theming here No way - as gtk is always themed. Your screenshot demonstrate that your gedit is not using 16x16 for icons. So either you're not using small-toolbar setting at all, or your theme defines it otherwise. since a lot of people are not running gnome or whatever window manager and just use stock gtk. See above. if you want to show the same as other apps, then you /have/ to look at the theme no matter what. But as long as OOo uses bitmap icons, I tend to /not/ adjust to the same size as other apps, but rather use the one of the two sizes that is closer to the desired size. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi I am *not* using any themes, it's the default GTK one. Anyways that does not matter now. On (2011-01-05 19:15), Christian Lohmaier wrote: Hi Robert, *, On Wed, Jan 5, 2011 at 7:02 PM, Robert Nagy rob...@openbsd.org wrote: We should just ignore all the theming here No way - as gtk is always themed. Your screenshot demonstrate that your gedit is not using 16x16 for icons. So either you're not using small-toolbar setting at all, or your theme defines it otherwise. since a lot of people are not running gnome or whatever window manager and just use stock gtk. See above. if you want to show the same as other apps, then you /have/ to look at the theme no matter what. But as long as OOo uses bitmap icons, I tend to /not/ adjust to the same size as other apps, but rather use the one of the two sizes that is closer to the desired size. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Robert, all! Am Mittwoch, den 05.01.2011, 18:32 +0100 schrieb Robert Nagy: Oh well then Linux is broken, again. :) In gedit the icons are bigger than the small ones but not as huge as in LibreOffice. Here you can see (LO with small icons): http://blade2k.humppa.hu/2011-01-05-182917_1920x1080_scrot.png Mmh, I'm unsure how much it helps to compare the different applications. * gedit is a native Gnome application and respects their desktop guidelines. -- 24x24 px toolbar icons, text below (always) * Firefox is a multi-platform application that (most of the time) respects platform specific rules -- 24x24 px toolbar icons, no text (which seems to be the default for Firefox) * LibreOffice is also multi-platform, but we care less about platform specific characteristics (mainly driven by saving effort ... for Windows, sharing toolbar and menu icons - no further comment on that) -- 16x16 px toolbar icons, no text As said, our small toolbar icons are 16x16 px, the larger ones are 26x26 px. Thus, there is no way to perfectly align LibO/OOo to what the Gnome Desktop defines/requires. Moreover, one of our main problems is, that we do offer too many toolbar elements per default ... thus we have to omit the labels and hitting the buttons gets harder (due to their small size). Increasing the icon size (better: automatic setting) will improve that, but we won't improve the understandability of the metaphors :-) Here is some more information ... Platform Differences (scroll a bit down, please) http://wiki.services.openoffice.org/wiki/Platform_UI_Differences#Differences How Toolbars and Labels are Used within Gnome http://library.gnome.org/devel/hig-book/stable/toolbars-labels-tooltips.html.en (ws robert 22435)$ xdpyinfo | egrep (dimensions|dots per inch) dimensions:1920x1080 pixels (518x291 millimeters) resolution:94x94 dots per inch It is strange for me tho that linux *hardcodes* 75. Where is taht hardcoded? I don't know whether this helps in general, but in Gnome there is a DPI setting that is used to scale the font display. At least for my screen is 96x96 DPI (using the command above). Cheers, Christoph On (2011-01-05 17:14), Michael Meeks wrote: Hi Robert, On Wed, 2011-01-05 at 16:24 +0100, Robert Nagy wrote: On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? Oh wait, I misunderstood. That is wrong. I am on a 1920x1080 display :-) so - as I say; the DPI is a constant of 75 across the Linux desktop, so this is not a switch but a hard coded setting :-) I am still convinced that large icons, on a reasonably sized screen give a -far- more useful view of the metaphore for a beginner user. As I say, advanced users can make it smaller. and i still prefer the small icons, it is like that in _every_ app. So we should stick to the DPI. Well; looking at gedit - it is using gtktoolbar.c's: #define DEFAULT_ICON_SIZE GTK_ICON_SIZE_LARGE_TOOLBAR ie. the same size (large) icons that we are using here. Perhaps the size setting is coming from the theme, in which case we should extract it and use exactly that setting in LibreOffice - can you have a dig ? (can you check that stock gtk+ apps do indeed have small toolbar icons ?). Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Linux] LibORC2: Impress video / `GLIBCXX_3.4.11' not found
On 01/05/2011 02:06 AM, Michael Meeks wrote: Hi there, On Fri, 2010-12-31 at 11:23 -0800, NoOp wrote: (soffice:22820): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /opt/libreoffice/program/../basis-link/ure-link/lib/libstdc++.so.6: Gack; another instance of our internal libstdc++ biting us hard. I wonder if using RTLD_DEEPBIND on this sort of component's dlopen might help us; hmm. If I: $ sudo cp /usr/lib/libstdc++.so.6 /opt/libreoffice3/ure/lib/ and $ sudo cp /usr/lib/libstdc++.so.6 /opt/libreoffice/ure/lib/ the video now runs without issue. It's a great bug report - thanks; as Kendy says having it in bugzilla would help. The hope is that vendors will use their native libstdc++ - so this affects only the generic builds. Can LibORC3 include an updated libstdc++.so.6 so that others do not have the same issue? Thanks. That might be a temporary solution too, Hmm, Michael. Bug filed: https://bugs.freedesktop.org/show_bug.cgi?id=32852 Thanks. Gary Lee ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
On 01/05/2011 12:14 PM, Michael Meeks wrote: Hi Robert, On Wed, 2011-01-05 at 16:24 +0100, Robert Nagy wrote: On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? Oh wait, I misunderstood. That is wrong. I am on a 1920x1080 display :-) so - as I say; the DPI is a constant of 75 across the Linux desktop, so this is not a switch but a hard coded setting :-) I think you are over-reaching here: scorpius pturmel ~ $ xdpyinfo | egrep (dimensions|dots per inch) dimensions:3600x1080 pixels (905x272 millimeters) resolution:101x101 dots per inch In fact, in several years of daily linux use, I've always had a reality-based DPI in X on single monitor systems, and lately, on my dual-monitor setups. I'd like to hear just which distributions are hardcoding DPI, and whether they are using 75 or some other. I am still convinced that large icons, on a reasonably sized screen give a -far- more useful view of the metaphore for a beginner user. As I say, advanced users can make it smaller. +1 My $0.02. Phil ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Change executable/sh names
On 01/05/2011 02:55 AM, Jesús Corrius wrote: On Wed, Jan 5, 2011 at 5:38 AM, NoOp gl...@sbcglobal.net wrote: ... Any progress on this? Would it help if I filed a bug report? This issue is (to me) critical regarding any further RC or full release of LibO. Sorry, I have been in Norway for more than week in a cabin without computers or internet connection. I'm envious. :-) I will send a patch very soon. Cheers, Thanks Happy New Year! Gary ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Fix passing distro specific branding via configure
Hi, the configure options --with-intro-bitmaps, --with-about-bitmaps did not longer worked. I think that nobody needs more pictures. The attached patches rename the above options to pass only one picture and fix the stuff to work. KAMI, could you sign it off for libreoffice-3-3 branch? Best Regards, Petr From aeb812f7f576e0eb092434f9191c41ba70d71782 Mon Sep 17 00:00:00 2001 From: Petr Mladek pmla...@suse.cz Date: Wed, 5 Jan 2011 19:27:15 +0100 Subject: [PATCH] Fix distro specific about intro hadling I guess that nobody uses more alternative branding pictures. It was implemented for SLED10-GM and it is not longer needed there. So I renamed: --with-intro-bitmaps to --with-intro-bitmap --with-about-bitmaps to --with-about-bitmap and INTRO_BITMAPS to INTRO_BITMAPS ABOUT_BITMAPS to ABOUT_BITMAP Also .png file format is requred instead of .bmp now. --- configure.in | 68 +++-- set_soenv.in |4 +- 2 files changed, 30 insertions(+), 42 deletions(-) diff --git a/configure.in b/configure.in index 266f7e3..d703dde 100644 --- a/configure.in +++ b/configure.in @@ -1091,20 +1091,18 @@ AC_ARG_WITH(dict, Usage: --with-dict=ENGB,ENUS,ITIT ],,) -AC_ARG_WITH(intro-bitmaps, -[ --with-intro-bitmapsPrefer the specified intro bitmaps over the - the default one. Can be more than one (separated by - commas), the order means priority of fallback if the - first does not exist (in the installed tree). +AC_ARG_WITH(intro-bitmap, +[ --with-intro-bitmapPrefer the specified intro bitmap over the + the default one. - Usage: --with-intro-bitmaps=/path/my_ooo_intro.bmp + Usage: --with-intro-bitmap=/path/my_ooo_intro.png ],,) -AC_ARG_WITH(about-bitmaps, -[ --with-about-bitmapsSimilarly to --with-intro-bitmaps, this allows - specification of bitmaps for the About box. +AC_ARG_WITH(about-bitmap, +[ --with-about-bitmapSimilarly to --with-intro-bitmap, this allows + specification of bitmap for the About box. - Usage: --with-about-bitmaps=/path/my_ooo_about.bmp + Usage: --with-about-bitmap=/path/my_ooo_about.png ],,) AC_ARG_WITH(vendor, @@ -7775,43 +7773,33 @@ else fi AC_SUBST(WITH_DICT) -AC_MSG_CHECKING([for additional 'intro' bitmaps]) -INTRO_BITMAPS= -if test -z $with_intro_bitmaps -o $with_intro_bitmaps = no ; then - INTRO_BITMAPS= +AC_MSG_CHECKING([for another 'intro' bitmap]) +INTRO_BITMAP= +if test -z $with_intro_bitmap -o $with_intro_bitmap = no ; then + INTRO_BITMAP= AC_MSG_RESULT([none]) else - for bitmap in `echo $with_intro_bitmaps | tr ',' ' '` ; do - case $bitmap in - *.bmp) ;; - *) bitmap= ; AC_MSG_WARN([Intro bitmaps should be .bmp files!]) ;; - esac - if test -n $bitmap ; then - INTRO_BITMAPS=$INTRO_BITMAPS $bitmap - fi - done - AC_MSG_RESULT([$INTRO_BITMAPS]) + case $with_intro_bitmap in + *.png) INTRO_BITMAP=$with_intro_bitmap ;; + *) AC_MSG_WARN([Intro bitmap should be a .png file!]) ;; + esac + AC_MSG_RESULT([$INTRO_BITMAP]) fi -AC_SUBST(INTRO_BITMAPS) +AC_SUBST(INTRO_BITMAP) -AC_MSG_CHECKING([for additional 'about' bitmaps]) -ABOUT_BITMAPS= -if test -z $with_about_bitmaps -o $with_about_bitmaps = no ; then - ABOUT_BITMAPS= +AC_MSG_CHECKING([for another 'about' bitmap]) +ABOUT_BITMAP= +if test -z $with_about_bitmap -o $with_about_bitmap = no ; then + ABOUT_BITMAP= AC_MSG_RESULT([none]) else - for bitmap in `echo $with_about_bitmaps | tr ',' ' '` ; do - case $bitmap in - *.bmp) ;; - *) bitmap= ; AC_MSG_WARN([About bitmaps should be .bmp files!]) ;; - esac - if test -n $bitmap ; then - ABOUT_BITMAPS=$ABOUT_BITMAPS $bitmap - fi - done - AC_MSG_RESULT([$ABOUT_BITMAPS]) + case $with_about_bitmap in + *.png) ABOUT_BITMAP=$with_about_bitmap ;; + *) AC_MSG_WARN([About bitmap should be a .png file!]) ;; + esac + AC_MSG_RESULT([$ABOUT_BITMAP]) fi -AC_SUBST(ABOUT_BITMAPS) +AC_SUBST(ABOUT_BITMAP) OOO_VENDOR= AC_MSG_CHECKING([for vendor]) diff --git a/set_soenv.in b/set_soenv.in index 6e51c4f..1c1e97b 100644 --- a/set_soenv.in +++ b/set_soenv.in @@ -1630,8 +1630,8 @@ else } # Languages ToFile( WITH_LANG, @WITH_LANG@, e ); -ToFile( INTRO_BITMAPS, @INTRO_BITMAPS@, e ); -ToFile( ABOUT_BITMAPS, @ABOUT_BITMAPS@, e ); +ToFile( INTRO_BITMAP, @INTRO_BITMAP@, e ); +ToFile( ABOUT_BITMAP, @ABOUT_BITMAP@, e ); ToFile( OOO_VENDOR,@OOO_VENDOR@, e ); ToFile( OOODMAKEMODE, YES, e ); ToFile( WITH_POOR_HELP_LOCALIZATIONS, @WITH_POOR_HELP_LOCALIZATIONS@, e ); -- 1.7.3.4 From be382496e55755f4aeb64d3de6ac19909399fe6b Mon
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h in drawpage.hxx/.cxx
Hi and thank you for your comments
2011/1/5 Kohei Yoshida kyosh...@novell.com:
Hi Sören,
Thanks for the patch. Is there a reason why this one is not an
attachment? :-)
It is not an attachment as I used git send-email to send it to the
mailing list, but the result seems a bit wierd when reading the list,
and it is not possible to give extra explanations in the mail when
sending the patch, so I think I will go back to attachments for my
next commits.
Anyway, I have some comments.
On Tue, 2011-01-04 at 20:20 +0100, Sören Möller wrote:
Replaced datatypes from tools/solar.h with corresponding types from
sal/types.h in drawpage.hxx/.cxx and added missing include of sal/types.h in
docparam.hxx
---
sc/inc/docparam.hxx | 1 +
sc/inc/drawpage.hxx | 4 ++--
sc/source/core/data/drawpage.cxx | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/sc/inc/docparam.hxx b/sc/inc/docparam.hxx
index 2511f26..01170a5 100644
--- a/sc/inc/docparam.hxx
+++ b/sc/inc/docparam.hxx
@@ -32,6 +32,7 @@
#ifndef SC_DOCPARAM_HXX
#define SC_DOCPARAM_HXX
+#include sal/types.h
#include address.hxx
This should not be necessary (though it won't hurt) as the address.hxx
already includes sal types. Does it not build without this change for
you?
It does build without the change for me, I did the change to ensure
that we don't break the file accidentially by changing includes of
address.hxx, although I now can see that this maybe isn't necessary
for such basic includes (types are quite standard and almost everyone
includes address.hxx). I think I felt it more important yesterday
after reading a lot of files using things from tools/ but only
including them through other includes, which would break the code, if
I would remove the tools/ parts from the other includes first.
// Let's put here misc structures that get passed to ScDocument's methods.
diff --git a/sc/inc/drawpage.hxx b/sc/inc/drawpage.hxx
index faa43fa..5e207b7 100644
--- a/sc/inc/drawpage.hxx
+++ b/sc/inc/drawpage.hxx
@@ -30,7 +30,7 @@
#define SC_DRAWPAGE_HXX
#include svx/fmpage.hxx
-
+#include sal/types.h
class ScDrawLayer;
@@ -39,7 +39,7 @@ class ScDrawLayer;
class ScDrawPage: public FmFormPage
{
public:
- ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, BOOL
bMasterPage=FALSE);
+ ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, sal_Bool
bMasterPage=sal_False);
~ScDrawPage();
virtual ::com::sun::star::uno::Reference
::com::sun::star::uno::XInterface createUnoPage();
diff --git a/sc/source/core/data/drawpage.cxx
b/sc/source/core/data/drawpage.cxx
index d489d5d..5a91540 100644
--- a/sc/source/core/data/drawpage.cxx
+++ b/sc/source/core/data/drawpage.cxx
@@ -44,7 +44,7 @@
// ---
-ScDrawPage::ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, BOOL
bMasterPage) :
+ScDrawPage::ScDrawPage(ScDrawLayer rNewModel, StarBASIC* pBasic, sal_Bool
bMasterPage) :
FmFormPage(rNewModel, pBasic, bMasterPage)
{
SetSize( Size( LONG_MAX, LONG_MAX ) );
For these two, let's use the standard bool type. In fact, its parent
class FmFormPage does expect a parameter of the bool type, not sal_Bool
nor BOOL (though the default value is for some reason set to sal_False
instead of false, which should really be fixed...), which provides
another reason to use bool, not sal_Bool.
I think I'm still too afraid of breaking UNO-things, if there just is
something UNO-related close to the code, when using native types, I
will try to be more confident in using bool, and believing in it, if
my build works out fine.
Regards
Sören
Thanks!
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] set RPATH correctly in the internal ICU
Hi,
our build service found broken RPATH in libicudata.so.42.1; it is fixed
by the attached patch
Cedric, could you please sign it off for libreoffice-3-3.
It works well on Linux with bash. I think that it can't be worse on
other systems ;-)
Best Regards,
Petr
From 1395e5600091d6d768690cb66181c9c3417343e1 Mon Sep 17 00:00:00 2001
From: Petr Mladek pmla...@suse.cz
Date: Wed, 5 Jan 2011 20:14:29 +0100
Subject: [PATCH] set RPATH correctly in the internal icu
RPATH must be set to $ORIGIN:$ORIGIN/../ure-link/lib; it was broken
in libicudata.so.42.1 because the $ORIGIN was substituted
the patch escapes '$' with '\' before using in the command 'echo'
---
patches/dev300/apply|2 +
patches/dev300/icu-4.2.1-rpath.diff | 36 +++
2 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 patches/dev300/icu-4.2.1-rpath.diff
diff --git a/patches/dev300/apply b/patches/dev300/apply
index e9232b1..4085d29 100755
--- a/patches/dev300/apply
+++ b/patches/dev300/apply
@@ -181,6 +181,8 @@ ok-cancel-btn-add-accel.diff, kohei
# Upgraded internal ICU to 4.2.1
icu-4.2.1.diff, cbosdo
+# pass $ORIGIN correctly to RPATH
+icu-4.2.1-rpath.diff. pmladek
[ TemporaryHacks ]
diff --git a/patches/dev300/icu-4.2.1-rpath.diff b/patches/dev300/icu-4.2.1-rpath.diff
new file mode 100644
index 000..02e8bec
--- /dev/null
+++ b/patches/dev300/icu-4.2.1-rpath.diff
@@ -0,0 +1,36 @@
+--- icu/icu4c-4_2_1-src-rpath.patch.old 2011-01-03 17:54:31.0 +0100
icu/icu4c-4_2_1-src-rpath.patch 2011-01-03 17:58:18.0 +0100
+@@ -0,0 +1,21 @@
++--- misc/icu/source/data/pkgdataMakefile.in 2010-12-22 23:44:02.0 +0100
+ misc/build/icu/source/data/pkgdataMakefile.in 2011-01-03 17:52:44.0 +0100
++@@ -15,6 +15,9 @@ include $(top_builddir)/icudefs.mk
++ OUTPUTFILE=icupkg.inc
++ MIDDLE_SO_TARGET=
++
+++# escape $ with \ when passing to echo; needed to preserve $ORIGIN
+++SHLIB.c.shell := $(subst $$,\$$,$(SHLIB.c))
+++
++ all : clean
++ @echo GENCCODE_ASSEMBLY_TYPE=$(GENCCODE_ASSEMBLY) $(OUTPUTFILE)
++ @echo SO=$(SO) $(OUTPUTFILE)
++@@ -24,7 +27,7 @@ all : clean
++ @echo LIB_EXT_ORDER=$(FINAL_SO_TARGET) $(OUTPUTFILE)
++ @echo COMPILE=$(COMPILE.c) $(OUTPUTFILE)
++ @echo LIBFLAGS=-I$(top_srcdir)/common -I$(top_builddir)/common $(SHAREDLIBCPPFLAGS) $(SHAREDLIBCFLAGS) $(OUTPUTFILE)
++- @echo GENLIB=$(SHLIB.c) $(OUTPUTFILE)
+++ @echo GENLIB=$(SHLIB.c.shell) $(OUTPUTFILE)
++ @echo LDICUDTFLAGS=$(LDFLAGSICUDT) $(OUTPUTFILE)
++ @echo LD_SONAME=$(LD_SONAME) $(OUTPUTFILE)
++ @echo RPATH_FLAGS=$(RPATH_FLAGS) $(OUTPUTFILE)
+--- icu/makefile.mk.old 2010-12-22 23:42:29.0 +0100
icu/makefile.mk 2011-01-03 17:55:27.0 +0100
+@@ -47,7 +47,8 @@ TARFILE_MD5=
+ TARFILE_ROOTDIR=icu
+
+ PATCH_FILES=\
+-${TARFILE_NAME}.patch
++${TARFILE_NAME}.patch \
++${TARFILE_NAME}-rpath.patch
+
+ # ADDITIONAL_FILES=
+
--
1.7.3.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Updates for Lightproof
Title: Szalai Kálmán Hi Michael, Sorry for bugging you but it seems I sent it two times, and David already pushed in: Re: [Libreoffice] [PATCH] [PUSHED] Updates for LightProof extension handling It is required If someone packs LightProof because of changed extension installation in 3.3. I hope LightProf will get more attention in the future. It is easy to adopt to other languages, uses Python, very effective and small. Thank you! Best regards, KAMI 2011-01-05 17:00 keltezéssel, Michael Meeks írta: Hi Kami, On Wed, 2010-12-22 at 18:28 +0100, Kálmán „KAMI” Szalai wrote: Please review the attached patch that provide updated support for Ligthproof extension integration for 3.3.x series. Looks lovely :-) but can we punt this for 3.3.1 ? I think we need to be getting into some really deep code freeze for 3.3.0 just now - I hope to have a final release / GMC of that in the next week or so. Thanks, Michael. -- Best regards, Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com My favorite projects: OxygenOffice Professional - office suite - for everybody | Magyarul - In Hungarian Blog | Support Follow me, if you can signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set RPATH correctly in the internal ICU
On Wed, 2011-01-05 at 20:22 +0100, Petr Mladek wrote: Hi, our build service found broken RPATH in libicudata.so.42.1 That libicudata is the biggest nuisance, causes all sorts of problems on different platforms. Rather an odd use of an elf file as data storage IIRC and manually created by icu rather than by the normal compiler +linker chain. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Bug 31865 depends on bug 32133, which changed state. Bug 32133 Summary: Overlapping controls on Tools - Options - General panel https://bugs.freedesktop.org/show_bug.cgi?id=32133 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] UX New layout Move/Copy sheet in calc
Michael, Sorry that I used the background color directly. I just do not known jet how to use themes. Is there a theme for displaying a warning label in a dialog? The color of the warning was inspired by the spec: http://wiki.services.openoffice.org/wiki/User_Experience/Projects/NonModalMessageSystem#Step_2_-_Message_Style_2a Where can I find the specs for the UI and UX for LibreOffice? Best regards, Joost 2011/1/5 Michael Meeks michael.me...@novell.com On Tue, 2011-01-04 at 23:03 +0100, Joost Eekhoorn wrote: Thanks for making the improvements. I haven't found a way to change the color of edit box either, so we can leave that a future project for now. Setting the background color is what I have used for the warning Soo ... in general setting manual colors that don't come from the theme is a disaster area for accessibility. aFtWarn.SetControlBackground( Color( COL_YELLOW ) ); There are whole schools-fulls-of users in the tropics that explode when they see the color yellow :-) [ or something like that ]. Seriously; any color we use for highlighting (or whatever) should come from the defined colors used for the rest of the app, and thus from some sort of system theme (ideally). That way it can be changed to be high-contrast / low-contrast etc. This is in part why you tend not to see yellow entries left/right :-) HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Christian! Am Mittwoch, den 05.01.2011, 19:40 +0100 schrieb Christian Lohmaier: Hi Christoph, *, On Wed, Jan 5, 2011 at 7:18 PM, Christoph Noack christ...@dogmatux.com wrote: [...] Mmh, I'm unsure how much it helps to compare the different applications. * gedit is a native Gnome application and respects their desktop guidelines. -- 24x24 px toolbar icons, text below (always) Well - not always. [...] You are right, maybe my always wasn't waterproof :-) There is also a setting that shows labels only for the less known/used icons - I wanted to say that the labels are shown for all toolbar icons. Anybody remembers IE5? :-) Sorry for the misleading formulation... Moreover, one of our main problems is, that we do offer too many toolbar elements per default ... thus we have to omit the labels and hitting the buttons gets harder (due to their small size). I disagree Hitting a button that is still 16x16 is not hard (on 1680x1050, even less so on smaller resolutions) unless you're disabled in some way, but in that case you probably use a bigger theme anyway. I disagree as well :-) http://en.wikipedia.org/wiki/Fitts%27s_law Hard might also refer to the effectiveness (speed) and/or the effort (likeliness of RSI) that is required to use a device that controls the mouse pointer (even via touchpad and/or TrackPoint). Example: People using their laptop in the train - in comparison to the desktop at home, one is confronted to environmental constraints (bumpy road), an incorrect body posture, and different / less accurate input devices. Thus, we have to take care that our default settings work well for the majority of users working in very different working conditions. By the way, even if some people don't like the idea - this is what Microsoft managed rather good with regard to the ribbons (MS Fluent) and the visual distinction (size, labeling) of the different toolbar buttons. [...] Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Christoph, *; On Wed, Jan 5, 2011 at 10:51 PM, Christoph Noack christ...@dogmatux.com wrote: [...] Thus, we have to take care that our default settings work well for the majority of users working in very different working conditions. [...] Yes, and that surely is the setting they use for their other apps, isn't it? ;- ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Symbolic regression for curvefitting.
Hi Kohei, Am Mittwoch, den 05.01.2011, 13:02 -0500 schrieb Kohei Yoshida: On Sun, 2011-01-02 at 21:12 +0100, Fabian Deutsch wrote: Thoughts? I think this is a pretty interesting project worth consideration. One thing I noticed; you've chosen Vala as the language for this library. Is that only for prototyping, or is that a permanent fixture? I choose vala to implement my prototype. This is not fixed and could be changed if someone is willing to port code :) In general it is not to hard to implement. I know nothing about Vala, but having to learn a new language does raise a bar for some of us to participate and take a peek at it. Okay. In general the code I pointed to in my last mail, should run on any modern distro (e.g. Fedora). In principle the vala code is translated to c, then it get's compiled in the classic way. All this is quite nicely integrated into autotools. Other than that, the project sounds interesting. I'd like to take a look at that at some point. That's great :) If questions arise, don't hesitate to contact me. - fabian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Test script patch review request (1)
Ah...got more reading. `expand` is smarter than I have thought ( I misunderstood it as only fixed space characters can be provided to replace tabs), so to keep the source file looks the same as it used to be. This should be enough to: $ cat /tmp/tabfile | while read fn ; do expand $fn /tmp/no_initabfile; mv /tmp/no_initabfile $fn; done Then removing trailing spaces. Is that the correct way? Best regards, Yifan On Wed, Jan 05, 2011 at 02:19:00AM -0700, Tor Lillqvist wrote: Would you also like to comment my updated method sent yesterday? Thanks! Well, it was not clear to me why you want to expand only initial tabs. Presumably when somebody uses tab characters in a source file, they intend them to tab to the next multiple of four columns regardless where on the line they are? That is how the editor shows the source files to the person editing it. Or am I missing something? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
