Re: [Libreoffice] LibreOffice Icon Naming
On 01/11/10 20:31, Andrew C. E. Dent wrote: Hi Andrew I'm another Andrew who also cares about Icons! (Normally people refer to me by my User name of 'ace_dent'). I first started to analyse the problem about 5yrs ago(!) but gave in under the original Sun ownership. I have started the bare seeds of this over on the wiki: http://wiki.documentfoundation.org/Development/Icon_Themes I'm first trying to move the work I did in an earlier audit of all the icons into the wiki, to move things forward. See here: http://people.bath.ac.uk/ea2aced/OOo/OOoIconCat.odt - Please jump in and get involved! I agreed with your points, however, I would like to split out large / small icons into two different zip archives. There is some performance reasons for doing this, and makes naming conventions easier, but I think I need some input from coding gurus... Cheers, Andrew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Hi Other Andrew :) Wow you seem to have done a lot of great work on this! However I see a few issues: Your proposed scheme would see icons categorised by components. Whilst I see you have the zero category for shared icons, I can see many problems with this in the future, where icons become duplicated, not in the correct categories. It also make it much harder for an artist, whereas in the extended tango spec which I have proposed an artist could easily find an icon by its context (i.e. action) in your one, they would have to go by component which may not always be obvious. I also think having the size in the filename is not a great idea as you will end up with VERY large directories where icons are not easily seen. Putting sizes into folder solves this problem. The Tango Icon Naming Spec has seen widespread adoption and has seen to work and so I (and kendy) believed it was the best way to go forward. It also makes things easier for icon authors coming from a GTK icon theme as most of the icon names will be the same. Please don't get me wrong, the work that you have done will be invaluable when it comes wrong to implementing it :) However I don't believe that your spec is necessarily the best way forward. Any comments? -- Andrew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Icons
Hi Joseph That's made my day!To make this more manageable, I think we should first agree on how to divide and conquer different aspects.A good starting point might be to fix up the fallback code: http://wiki.documentfoundation.org/Easy_Hacks#don.27t_ship_150_duplicate_placeholder_iconsDo you use the #libreoffice IRC channel? Perhaps I can catch you there depending on timezones? I will compose a more detailed email later, and look forward to working (/hacking) with you. Cheers,Andrew From: jpower...@cox.net Subject: Icons Date: Mon, 1 Nov 2010 21:15:51 -0700 CC: libreoffice@lists.freedesktop.org To: ace_d...@hotmail.com Andrew, I'm a little crazy, but I want to work on the icon issues. I'm a programmer, so I've been looking at things from the other side... Currently the system is a mess, the top level determines if if we're in high-contrast mode or not and then requests the correct image. On top of this, we have both themed and un-themed icons; thus, I can't just kill the high-contrast checks. From your earlier e-mails, you've said that each theme has both standard icons and high-contrast icons; this has to change. However, I'm stuck trying to figure out how the code knows which icon file it's requesting. The un-themed icons in chart2 are easy to tack since I found the mapping files; however, I'm having issues with the themed icons. I believe all the themes should be located the /artwork directory and we'll need to create a system for building/packaging them for inclusion into the project. We'll also need to determine a directory to house the installed themes. The current system of themes being hard coded into the build system needs to change; the users should be able to just drop a theme package and have the them auto-reconized on the change theme dialog. I'm open to suggestions from any of the other developers. I'm also in need of guidance in under standing the current icon packaging system. As far as I can determine the biggest savings would be to do the changes in this order: 1. Remove the High-Contrast check from the themed icons. a) This should cut the themes in about half. b) Reduce a lot of code over head. 2. Move the un-themed icons in to the default themes. a) This only removes some redundant code paths for retrieving icons. b) Removes the last of the High-Contrast checks. c) Will need to verify that the missing icon fall-back code actually works. 3. Make themes discoverable. a) No real savings, it's mostly a coolness factor. Plus it gives the graphics designers something to do so they leave the programmers alone. Joe P. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] (no subject)
Hi, a little bit more... regards. createFromAscii_8.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] bootstrap/soenv: remove tcsh version of LinuxX86-64Env.Set
Previously we would have been writing out LinuxX86-64Env.Set and
LinuxX86-64Env.Set.sh which made my autocompletion useless. Simplify the
set_soenv.in to actually only produce 1 version which makes us require
bash as interactive build shell.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
Here is the resend after the branching to be applied in master as
requested my Michael.
I have tested the correct function of this patch on x86_64 Linux and I don't
see any reason why it should break on other platforms. I don't know how fragile
Windows is in that regard though.
set_soenv.in | 117 +-
1 files changed, 42 insertions(+), 75 deletions(-)
diff --git a/set_soenv.in b/set_soenv.in
index 5a3313c..7f55e47 100644
--- a/set_soenv.in
+++ b/set_soenv.in
@@ -38,12 +38,12 @@ use File::Basename;
# IIa. Declaring variables for the system commands, etc.
#
#
-my ( $outfile, $outfile_sh, $bootfile, $newline, $comment,
+my ( $outfile, $bootfile, $newline, $comment,
$compiler, $unsetenv, $setenv, $unset, $set, $ds, $ps,
$wps, $cur_dir, $par_dir, $I, $L, $D, $buildenv, $answer, $tmp, $MINGW,
$USE_MINGW, $platform,
$cygwinver, $empty, $no_ant, $no_stl, $no_gcc_include,
- $no_gxx_include, $warnfile, $Warning, $result, $unsetvars, $unsetvarssh,
$unsetvarsbat, $exportvars, $win_format_var, $perl_os,
@mingw_lib_include_paths, $mingw_lib_include_path);
+ $no_gxx_include, $warnfile, $Warning, $result, $unsetvars, $exportvars,
$win_format_var, $perl_os, @mingw_lib_include_paths, $mingw_lib_include_path);
#
#-
# IIb. Declaring environment values (constants).
@@ -205,10 +205,10 @@ if ( $platform =~ m/solaris/ )
if ($platform =~ m/^i[3456]86/)
{
if ( $CC =~ gcc) {
- $outfile= SolarisX86GccEnv.Set;
+ $outfile= SolarisX86GccEnv.Set.sh;
$OUTPATH= unxsogi;
} else {
- $outfile= SolarisX86Env.Set;
+ $outfile= SolarisX86Env.Set.sh;
$OUTPATH= unxsoli4;
}
$CPU= I;
@@ -221,10 +221,10 @@ if ( $platform =~ m/solaris/ )
else
{
if ( $CC =~ gcc) {
- $outfile= SolarisSparcGccEnv.Set;
+ $outfile= SolarisSparcGccEnv.Set.sh;
$OUTPATH= unxsogs;
} else {
- $outfile= SolarisSparcEnv.Set;
+ $outfile= SolarisSparcEnv.Set.sh;
$OUTPATH= unxsols4;
}
$CPU= S;
@@ -256,7 +256,7 @@ elsif ( $platform =~ m/netbsd/ )
#Set platform specific values:
if ($platform =~ m/^i[3456]86/)
{ print Setting NetBSD x86 specific values... ;
- $outfile= NetBSDX86Env.Set;
+ $outfile= NetBSDX86Env.Set.sh;
$CPU= I;
$CPUNAME= INTEL;
$OUTPATH= unxbsdi;
@@ -266,7 +266,7 @@ elsif ( $platform =~ m/netbsd/ )
}
elsif ($platform =~ m/^sparc/)
{ print Setting NetBSD Sparc specific values... ;
- $outfile= NetBSDSparcEnv.Set;
+ $outfile= NetBSDSparcEnv.Set.sh;
$CPU= S;
$CPUNAME= SPARC;
$OUTPATH= unxbsds;
@@ -276,7 +276,7 @@ elsif ( $platform =~ m/netbsd/ )
}
elsif ($platform =~ m/powerpc/)
{ print Setting NetBSD PPC specific values... ;
- $outfile= NetBSDPPCEnv.Set;
+ $outfile= NetBSDPPCEnv.Set.sh;
$CPU= P;
$CPUNAME= POWERPC;
$OUTPATH= unxbsdppc;
@@ -319,7 +319,7 @@ elsif ( $platform =~ m/kfreebsd/ )
#Set platform specific values:
if ($platform =~ m/^i[3456]86/)
{ print Setting GNU/kFreeBSD x86 specific values... ;
- $outfile= GNUkFreeBSDX86Env.Set;
+ $outfile= GNUkFreeBSDX86Env.Set.sh;
$CPU= I;
$CPUNAME= INTEL;
$OUTPATH= unxkfgi6;
@@ -331,7 +331,7 @@ elsif ( $platform =~ m/kfreebsd/ )
}
elsif ($platform =~ m/^x86_64/)
{ print Setting GNU/kFreeBSD x86-64 specific values... ;
- $outfile= GNUkFreeBSDX86-64Env.Set;
+ $outfile= GNUkFreeBSDX86-64Env.Set.sh;
$CPU= X;
$CPUNAME= X86_64;
$OUTPATH= unxkfgx6;
@@ -357,7 +357,7 @@ elsif ( $platform =~ m/freebsd/ )
if ($platform =~ m/^amd64/)
{ my ( $JAVA_OS );
print Setting FreeBSD AMD64 specific values... ;
- $outfile= FreeBSDAMDEnv.Set;
+ $outfile= FreeBSDAMDEnv.Set.sh;
$CPU= X;
$CPUNAME= X86_64;
$OUTPATH= unxfbsdx;
@@ -376,7 +376,7 @@ elsif ( $platform =~ m/freebsd/ )
}
elsif ($platform =~ m/^i386/)
{ print Setting FreeBSD x86 specific values... ;
- $outfile= FreeBSDX86Env.Set;
+ $outfile=
[Libreoffice] [PATCH] bootstrap/set_soenv: remove unused variables
The variables $unsetenv, $setenv, $unset, $set $D, $answer were unused in this script and have been removed. Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de --- set_soenv.in | 11 ++- 1 files changed, 2 insertions(+), 9 deletions(-) diff --git a/set_soenv.in b/set_soenv.in index 7f55e47..b4b1616 100644 --- a/set_soenv.in +++ b/set_soenv.in @@ -1,8 +1,6 @@ #...@perl@ -w # # Program: set_soenv.in -# Version: $Revision: 1.201 $ -# Date:$Date: 2008-09-05 14:14:29 $ # Author: Willem van Dorp, Ross Nicholson, Oisin Boydell - Sun Microsystems, Ireland. # #--- @@ -39,8 +37,8 @@ use File::Basename; # # my ( $outfile, $bootfile, $newline, $comment, - $compiler, $unsetenv, $setenv, $unset, $set, $ds, $ps, - $wps, $cur_dir, $par_dir, $I, $L, $D, $buildenv, $answer, $tmp, $MINGW, + $compiler, $ds, $ps, + $wps, $cur_dir, $par_dir, $I, $L, $tmp, $MINGW, $USE_MINGW, $platform, $cygwinver, $empty, $no_ant, $no_stl, $no_gcc_include, $no_gxx_include, $warnfile, $Warning, $result, $unsetvars, $exportvars, $win_format_var, $perl_os, @mingw_lib_include_paths, $mingw_lib_include_path); @@ -110,10 +108,6 @@ chomp( $platform ); $UPD= '@UPD@'; # the project's UPD $newline= \n; # Perl newline character -$unsetenv = unsetenv; # c-shell command -$setenv = setenv; # c-shell command -$unset = unset; # msdos batch file command -$set= set;# msdos batch file command $ds = /; # directory separator $ps = :; # path separator $wps= :; # path separator, will be set to ';' for windows later. @@ -121,7 +115,6 @@ $cur_dir= .; # current directory $par_dir= ..; # parrent directory $I = -I;# include search path $L = -L;# library search path -$D = -D;# define search path $empty = ; # used as argument $no_stl = NO_STLPORT4;# possible argument $warnfile = warn; # logfile configure warnings. -- 1.7.1 pgpRfQ1rvyd90.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Another Qt/gtk configure patch
On Mon, 01 Nov 2010 22:18:46 +, Wols Lists wrote: I've now got configure autodetecting Qt4, and created an automagic patch. Things are still partly broken because to fix things properly I need to get rid of OOO_WIDGET_FLAGS, and that's probably a big job ... Adds a new --enable-automagic option. Shouldn't automagic be the default? ie building support for whatever is available on the machine sounds a sensible default to me. People/Packagebuilder can still manually enable/disable support fot things. /me shrugs. Not sure. Sebastian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice Icon Naming
Hi Andrew Almost missed your messages as I'm not subscribed to the list. Make sure you include my email when replying. :-) The Icon Audit is clearly outdated. It was started at the same time the Freedesktop naming spec was being developed (as used by Tango and others).The Wiki represents the current plan, but I want to transfer across the good stuff from my original document as a starting point. I think different icon sizes should not exist within the same zip archive for a theme to avoid overheads/ faster load time. But this is something to discuss with developer input. I will be on IRC this evening to discuss Icons with anyone who is about. Cheers,Andrew From: ace_d...@hotmail.com To: libreoffice@lists.freedesktop.org; rugby...@gmail.com Subject: Re: [Libreoffice] LibreOffice Icon Naming Date: Mon, 1 Nov 2010 20:31:52 + Hi Andrew I'm another Andrew who also cares about Icons! (Normally people refer to me by my User name of 'ace_dent').I first started to analyse the problem about 5yrs ago(!) but gave in under the original Sun ownership.I have started the bare seeds of this over on the wiki:http://wiki.documentfoundation.org/Development/Icon_Themes I'm first trying to move the work I did in an earlier audit of all the icons into the wiki, to move things forward. See here:http://people.bath.ac.uk/ea2aced/OOo/OOoIconCat.odt - Please jump in and get involved! I agreed with your points, however, I would like to split out large / small icons into two different zip archives. There is some performance reasons for doing this, and makes naming conventions easier, but I think I need some input from coding gurus... Cheers,Andrew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] EasyHack RTL_CONSTASCII_USTRINGPARAM in sc
On Mon, 2010-11-01 at 22:27 -0400, Kohei Yoshida wrote: Hello Joost, Thanks for the patch. Just pushed to the master branch. :-) Nothing to do with the patch, but I see a ConvertCountryCode which, depending on what it does, might be a candidate to be moved into i18npool/source/isolang beside the rest of the code that handles conversion to/from iso language names. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice and Java
On Wed, 2010-10-20 at 01:50 +0200, Cesare Leonardi wrote: Hi all. There's a thing not clear to me and that involved go-oo too: the relationship between LibreOffice and Java. Here i'm referring to the Windows environment but under Linux/Mac should be the same. Java isn't provided with the installer as with OpenOffice... Hmm, yeah, that's true. I believe this is due to uncertainty around the various clauses in the Redistribution text in the stock Java licence, so safest option was not to redistribute it as part of the stock windows installer bundle. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Icons
Hi Joseph, On Mon, 2010-11-01 at 21:15 -0700, Joseph Powers wrote: I'm a little crazy, but I want to work on the icon issues. Cool - there is a rich seam of wasted run-time memory, startup-time, and worse bloat in the Win32 packages here, all of which can be easily fixed I think :-) I'm a programmer, so I've been looking at things from the other side... Great news; perhaps good to put your name in the Easy Hacks as working on this task. Currently the system is a mess, the top level determines if if we're in high-contrast mode or not and then requests the correct image. On top of this, we have both themed and un-themed icons; thus, I can't just kill the high-contrast checks. Right - so - there is an easy hack for this: http://wiki.documentfoundation.org/Development/Easy_Hacks#un-screw-up_accessible_icon_code-paths_.26_shrink_theme_files We need to totally remove all references to 'BmpColorMode' that are used for selecting accessible vs. non-accessible icons - it is a total joke of an attempt at accessibility :-) Similarly - we should chase all -icon- code down that has special cases for high-contrast and remove it. Whomever implemented a11y had (apparently) no idea that there is are also -low-contrast- impairments as well as high-contrast ones :-) and the mechanism is fundamentally inextensible, as well as made obsolete by high-level theming. From your earlier e-mails, you've said that each theme has both standard icons and high-contrast icons; this has to change. However, I'm stuck trying to figure out how the code knows which icon file it's requesting. The un-themed icons in chart2 are easy to tack since I found the mapping files; however, I'm having issues with the themed icons. Well; there are lots of hacks through the code: svtools/source/contnr/templwin.cxx:bLarge ? bHiContrast ? IMG_SVT_DOCTEMPL_HC_BACK_LARGE : IMG_SVT_DOCTEMPLATE_BACK_LARGE The switch as to whether to do this is often fetched from: sal_Bool bHiContrast = GetSettings().GetStyleSettings().GetHighContrastMode(); Almost every instance of this call is a bug ;-) if it is for an icon - then it should be done using theming; if it is for a color - it should be done by building different style themes in vcl and using generic methods to fetch colors. I believe all the themes should be located the /artwork directory and we'll need to create a system for building/packaging them for inclusion into the project. We'll also need to determine a directory to house the installed themes. The current system of themes being hard coded into the build system needs to change; the users should be able to just drop a theme package and have the them auto-reconized on the change theme dialog. Yep - sounds great :-) Currently our hicontrast theme is built by packimages/pack/makefile.mk: # generate the HiContrast icon set $(MISC)$/hicontrast.flag .PHONY : $(PERL) $(SOLARENV)$/bin$/hicontrast-to-theme.pl $(SOLARSRC)$/default_images $(MISC)$/hicontrast $(TOUCH) $@ Which runs a script that build that theme. Of course - that theme has the worst of all worlds: exact duplicates of each icon twice - once as plain, once as hi contrast. I'm open to suggestions from any of the other developers. So ! :-) I suggest that we start by using the above perl script to create an entirely new theme (in artwork/) hicontrast - that is essentially the results of hicontrast-to-theme.pl - with all of the 'h' variants removed from it. I suggest we then remove the 'h' variants from default-images incrementally - as we remove their usage. So - we audit the GetHighContrastMode calls to find the one that will switch all the toolbar icons from lc_foo.png to lch_foo.png [ this will be in the 'framework' module and dependents ]. Then we remove all of that cruft; in the code, and simultaeously remove res/commandimagelist/lch_* and sch_* from default_images/ Then we iterate, incrementally removing more cruft left right, until we substantially shrink the size of images.zip :-) As far as I can determine the biggest savings would be to do the changes in this order: 1. Remove the High-Contrast check from the themed icons. a) This should cut the themes in about half. b) Reduce a lot of code over head. Right :-) 2. Move the un-themed icons in to the default themes. a) This only removes some redundant code paths for retrieving icons. b) Removes the last of the High-Contrast checks. c) Will need to verify that the missing icon fall-back code actually works. Sounds fine; I don't know how many un-themed images we have left; I suspect few enough. 3. Make themes discoverable. a) No real savings, it's mostly a coolness factor. Plus it gives the graphics designers something to do so they leave the programmers alone. Sounds cool
Re: [Libreoffice] [PATCH] bootstrap: disable-binfilter in inner configure by default
On Mon, 2010-11-01 at 12:27 -0500, Norbert Thiebaud wrote: The only draw-back its that even less people will build it, which means that breakage will go unnoticed longer (and yes it is possible to break binfilter without touching it -- been there, done that :-) ) That's the only reason I have for keeping it enabled by default. I'm not against disabling it by default if someone wants to do that. I know it unloved, and horrific, and the amount of .sdw etc documents around are comparatively small. Though as the only means of importing that legacy format I'd like to keep it undeleted, albeit with an eye to something like getting it munged into a standlone buildable separate extention or something. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Another Qt/gtk configure patch
On Monday 01 of November 2010, Wols Lists wrote: Has anybody still got a KDE3 system? Can you send me the relevant pkg-config file from /usr/libX/pkgconfig/ so I can try and get that to autodetect? KDE3 does not provide pkgconfig files, only Qt3. You can check what is provided e.g. at http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_11.3/x86_64/ (qt3-devel and kdelibs3-devel packages). Also, just checking for QtCore.pc and enabling KDE4 support based on that is wrong. Presence of libQtCore neither means all required Qt4 libraries are present nor KDE4 is present. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice and Java
On Tue, 2010-11-02 at 12:47 +, Michael Meeks wrote: Quite; cf. such uncertainty - it probably makes considerable sense to look into a migration strategy from Java to (insert anything else). Some candidates might be python for the more scripty pieces (though I hate non-typed languages), and/or native C++. What about the existing Java extensions? Quite a lot of people are using Java to either writer extensions or use UNO Java bridge from an external application. -- 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] [PATCH] Another Qt/gtk configure patch
On 02/11/10 13:23, Lubos Lunak wrote: On Monday 01 of November 2010, Wols Lists wrote: Has anybody still got a KDE3 system? Can you send me the relevant pkg-config file from /usr/libX/pkgconfig/ so I can try and get that to autodetect? KDE3 does not provide pkgconfig files, only Qt3. You can check what is provided e.g. at http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_11.3/x86_64/ (qt3-devel and kdelibs3-devel packages). Thanks. I'll take a look. Also, just checking for QtCore.pc and enabling KDE4 support based on that is wrong. Presence of libQtCore neither means all required Qt4 libraries are present nor KDE4 is present. I had a nasty suspicion that might be the case. But that means digging into libreoffice.../configure.in (which I was expecting to have to do, anyway ...) Is KDE support fundamentally different from gtk support? Bearing in mind that OOo seems to treat them as equivalent, but KDE is a DE while gtk is a toolkit? The main aim was to improve on what we had at present :-) Bearing in mind the automagic stuff as well, it looks like I'm going to be redoing that, so I might as well redo this at the same time. Hey-ho. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Mac OS X Build issues.
I'm not sure why this started by the following patch fixes the issue. 0001-Fix-build-issues.patch Description: Binary data Not sure if this is the correct patch (suggested by LeMoyne, I wasn't sure if I should fix the pl or fix the inputs...), but it builds and runs on Mac OS X. Form the file name, I'm assuming it doesn't run on the other systems. Joe P. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-automagic
On 02/11/10 12:34, Rene Engelhard wrote: On Tue, Nov 02, 2010 at 09:10:23AM +, Wols Lists wrote: In particular, there's a page on the gentoo wiki (I've put a pointer to it in our development wiki) that says that automatically enabling things can be a packager's nightmare. They've only got to miss a disable for True. some weird option they happen to have installed, and next thing they know they've shipped a package that depends on this weird option - AND DOESN'T DOCUMENT THAT FACT! This is not a big deal for runtime deps, both rpm and deb have mechanisms to find out what libs executables/libs need and putting them into Depends.. If you have a own system, you have to implement such stuff on your own anyways, so... I need to re-read that gentoo page (as a gentoo user I really ought to make sure I understand it :-) And not all distros use rpm/deb :-) the whole point of the gentoo page iiui is that upstream sometimes do silly things that makes their life difficult. For build-dependencies you're right, that can get a nightmare. Or you forget one option, and in a clean chroot the package is not installed - feature not there. Or even worse, you get additional stuff in unclean chroots you didn't expect and maybe don't even want. That's why, imho, disable-automagic is important (and that's why it's called magic not matic :-). If that happens, it's now an upstream bug, not a silly packager. And it's easy for us to fix each option as we add it, not so easy for them to spot we've enabled something obscure. Though, but a --enable/--dsiable-automagic is not senseful either. Sorry - I can't parse that :-) It's obvious you're German so something's got lost in the translation ... Norbert suggested a packager mode flag, but that's basically just a rename of this flag. At the end of the day, the devs (quite reasonably) want everything to be on by default, packagers afaict want it off. Do we keep this flag, or rename it, or is there another way to do it? Grüße/Regards, René Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug Triage Process
On 02/11/10 06:58, Muthu Subramanian K wrote: If you are able to reproduce and confirm, please do go ahead and assign it to one of the developers listed on the page. [The intention was to avoid lower.priority-and-unconfirmed issues to be assigned to the experts - it might take expert's time just to test-moreinfo-... cycle] - who is our expert for Base? hmm...as far as I know: nobody as of now, Any volunteers? Dare I? When I progress from hacking on configure.in, this looks like it might be the obvious progression. I'm a database programmer, very interested in how databases work. But I'm also very firmly in the NoSQL camp. I like relational *theory*, but the *practice* is broken (don't get me started :-) So count me in as a potential candidate. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-automagic
On Tue, Nov 2, 2010 at 9:26 AM, Wols Lists antli...@youngman.org.uk wrote: On 02/11/10 12:34, Rene Engelhard wrote: On Tue, Nov 02, 2010 at 09:10:23AM +, Wols Lists wrote: In particular, there's a page on the gentoo wiki (I've put a pointer to it in our development wiki) that says that automatically enabling things can be a packager's nightmare. They've only got to miss a disable for True. some weird option they happen to have installed, and next thing they know they've shipped a package that depends on this weird option - AND DOESN'T DOCUMENT THAT FACT! This is not a big deal for runtime deps, both rpm and deb have mechanisms to find out what libs executables/libs need and putting them into Depends.. If you have a own system, you have to implement such stuff on your own anyways, so... I need to re-read that gentoo page (as a gentoo user I really ought to make sure I understand it :-) And not all distros use rpm/deb :-) the whole point of the gentoo page iiui is that upstream sometimes do silly things that makes their life difficult. For build-dependencies you're right, that can get a nightmare. Or you forget one option, and in a clean chroot the package is not installed - feature not there. Or even worse, you get additional stuff in unclean chroots you didn't expect and maybe don't even want. That's why, imho, disable-automagic is important (and that's why it's called magic not matic :-). If that happens, it's now an upstream bug, not a silly packager. And it's easy for us to fix each option as we add it, not so easy for them to spot we've enabled something obscure. Though, but a --enable/--dsiable-automagic is not senseful either. Sorry - I can't parse that :-) It's obvious you're German so something's got lost in the translation ... Norbert suggested a packager mode flag, but that's basically just a rename of this flag. more a reversal of the default: I see it as: default is 'automagic=true' (more exactly 'not having --maintainer-mode') and it do a best effort to build with what you have that way a causal haker can do ./configure and it does something sensible based on the environement. if you want a speficifc distro-pattern use --with-distro= (which whould disable the automagic things) (you can still override individual by adding --with-xxx --enable-xxx etc. if you want to pick exactly what you want: --maintainer-mode, with the exhaustive list of everything that need choosing. (note: as a side effect, when a new options show up, distro-profile will break... which is a good thing, since distro maitainer should make a decision about that new options... and that will certainly attract their attention :-) ) LO dev can use --with-distro=LibreOfiiceDev, that will activate as much thing as possible At the end of the day, the devs (quite reasonably) want everything to be on by default, packagers afaict want it off. Do we keep this flag, or rename it, or is there another way to do it? Grüße/Regards, René Cheers, Wol ___ 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
[Libreoffice] [PATCH] Easy Hacks : Use RTL_CONSTASCII_USTRINGPARAM macro 6
Hi, some more in impress Regards. createFromAscii_9.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Presentation Wizard
Hey Everyone, So recently I was looking (and trying to use!) the Presenation Wizard that comes up when a user clicks FileNewPresentation (or Presentation of the Start screen). I came up with the conclusion that it was not easy-to-use, confusing and also a bit outdated. Problems I came across were: * Outdated look (yes I am looking at you top banner...) * Unclear concepts of templates and presentation backgrounds * Confusing options * Different terminology used between application and wizard and more... The annoying thing is, is that the idea of a wizard (in my mind) is very good, however a poor implementation is what we currently have. One thing that I love about LibO is the start screen, I really like the look of it, it is easy to use and looks very modern, however I realised it is HEAVILY underused. Therefore I decided to redesign the wizard, and integrate it into this start screen, you can see my results at: http://imagebin.ca/img/K-t66G.png --- First of all I wanted to make sure that power-users (such as myself) who just want to start with a blank presentation are catered for. therefore you see in the first screen that a user simply has to click one button and they have a blank presentation. However for those who wish to use the wizard, here is where it starts to get good... First of all I made a distinction between presentation styles (currently backgrounds) and presentation purpose (currently templates). What I envisage is that a style, (could have any name really) is something which just controls how a presentation looks (colours, fonts, layout etc.) A presentation purpose should be around content, what is it for and therefore what pages should it include. I also redesigned options, such as what the presentation will be shown on, and changed the wording so it is easier to understand. Terminology such as effect, speed, on mouse click, automatically after were copied over form the main application for consistency. --- Anyway I hope you can see my ideas and ideally, I envisage that each document type would have a similiar type of wizard for a consistent approach (word documents, spreadsheets etc.) If we decide that this is what we want, then I can make a design spec for this mockup, so that someone could implement it. Any comments? :) -- Andrew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] EasyHack RTL_CONSTASCII_USTRINGPARAM in sc
MPL 1.1 / GPLv3+ / LGPLv3+
Joost
diff --git a/sc/source/ui/vba/vbaassistant.cxx b/sc/source/ui/vba/vbaassistant.cxx
index 43ab458..b52a165 100644
--- a/sc/source/ui/vba/vbaassistant.cxx
+++ b/sc/source/ui/vba/vbaassistant.cxx
@@ -38,12 +38,12 @@ using namespace ooo::vba;
using namespace ooo::vba::office::MsoAnimationType;
-ScVbaAssistant::ScVbaAssistant( const uno::Reference XHelperInterface xParent, const uno::Reference uno::XComponentContext xContext ): ScVbaAssistantImpl_BASE( xParent, xContext )
+ScVbaAssistant::ScVbaAssistant( const uno::Reference XHelperInterface xParent, const uno::Reference uno::XComponentContext xContext ): ScVbaAssistantImpl_BASE( xParent, xContext ),
+m_sName( RTL_CONSTASCII_USTRINGPARAM( Clippit ) )
{
m_bIsVisible = sal_False;
m_nPointsLeft = 795;
m_nPointsTop = 248;
-m_sName = rtl::OUString::createFromAscii( Clippit );
m_nAnimation = msoAnimationIdle;
}
diff --git a/sc/source/ui/vba/vbaaxis.cxx b/sc/source/ui/vba/vbaaxis.cxx
index 9e17b30..a1f0dc3 100644
--- a/sc/source/ui/vba/vbaaxis.cxx
+++ b/sc/source/ui/vba/vbaaxis.cxx
@@ -47,7 +47,7 @@ ScVbaAxis::getChartPtr() throw( uno::RuntimeException )
{
ScVbaChart* pChart = static_cast ScVbaChart* ( moChartParent.get() );
if ( !pChart )
-throw uno::RuntimeException( rtl::OUString::createFromAscii(Can't access parent chart impl), uno::Reference uno::XInterface () );
+throw uno::RuntimeException( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(Can't access parent chart impl)), uno::Reference uno::XInterface () );
return pChart;
}
diff --git a/sc/source/ui/vba/vbainterior.cxx b/sc/source/ui/vba/vbainterior.cxx
index f3ea1b0..5b4df99 100644
--- a/sc/source/ui/vba/vbainterior.cxx
+++ b/sc/source/ui/vba/vbainterior.cxx
@@ -261,7 +261,7 @@ ScVbaInterior::GetMixedColorComp( sal_uInt8 nFore, sal_uInt8 nBack, sal_uInt8 n
uno::Reference container::XNameContainer
ScVbaInterior::GetAttributeContainer()
{
-return uno::Reference container::XNameContainer ( m_xProps-getPropertyValue( rtl::OUString::createFromAscii( UserDefinedAttributes ) ), uno::UNO_QUERY_THROW );
+return uno::Reference container::XNameContainer ( m_xProps-getPropertyValue( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( UserDefinedAttributes )) ), uno::UNO_QUERY_THROW );
}
sal_Int32
ScVbaInterior::GetAttributeData( uno::Any aValue )
@@ -277,8 +277,8 @@ uno::Any
ScVbaInterior::SetAttributeData( sal_Int32 nValue )
{
xml::AttributeData aAttributeData;
-//aAttributeData.Namespace = rtl::OUString::createFromAscii( ooo.vba.excel.CellPatten);
-aAttributeData.Type = rtl::OUString::createFromAscii( sal_Int32 );
+//aAttributeData.Namespace = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( ooo.vba.excel.CellPatten));
+aAttributeData.Type = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( sal_Int32 ));
aAttributeData.Value = rtl::OUString::valueOf( nValue );
return uno::makeAny( aAttributeData );
}
@@ -301,7 +301,7 @@ ScVbaInterior::SetUserDefinedAttributes( const rtl::OUString sName, const uno::
if( xNameContainer-hasByName( sName ) )
xNameContainer-removeByName( sName );
xNameContainer-insertByName( sName, aValue );
-m_xProps-setPropertyValue( rtl::OUString::createFromAscii( UserDefinedAttributes ), uno::makeAny( xNameContainer ) );
+m_xProps-setPropertyValue( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( UserDefinedAttributes )), uno::makeAny( xNameContainer ) );
}
}
// OOo do not support below API
@@ -323,7 +323,7 @@ ScVbaInterior::setPattern( const uno::Any _pattern ) throw (uno::RuntimeExcepti
SetMixedColor();
}
else
-throw uno::RuntimeException( rtl::OUString::createFromAscii( Invalid Pattern index ), uno::Reference uno::XInterface () );
+throw uno::RuntimeException( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( Invalid Pattern index )), uno::Reference uno::XInterface () );
}
Color
ScVbaInterior::GetBackColor()
@@ -371,7 +371,7 @@ ScVbaInterior::setPatternColor( const uno::Any _patterncolor ) throw (uno::Runt
SetMixedColor();
}
else
-throw uno::RuntimeException( rtl::OUString::createFromAscii( Invalid Pattern Color ), uno::Reference uno::XInterface () );
+throw uno::RuntimeException( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( Invalid Pattern Color )), uno::Reference uno::XInterface () );
}
uno::Any SAL_CALL
ScVbaInterior::getPatternColorIndex() throw (uno::RuntimeException)
@@ -394,7 +394,7 @@ ScVbaInterior::setPatternColorIndex( const uno::Any _patterncolorindex ) throw
setPatternColor( uno::makeAny( OORGBToXLRGB( nPattColor ) ) );
}
else
-throw uno::RuntimeException( rtl::OUString::createFromAscii( Invalid Pattern Color ), uno::Reference uno::XInterface () );
+throw uno::RuntimeException( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( Invalid Pattern Color )), uno::Reference uno::XInterface () );
}
rtl::OUString
diff
[Libreoffice] [PUSHED] Re: EasyHack RTL_CONSTASCII_USTRINGPARAM in sc
On Tue, 2010-11-02 at 20:43 +0100, Joost Eekhoorn wrote: MPL 1.1 / GPLv3+ / LGPLv3+ All look good, thanks, now pushed :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Easy Hacks : Use RTL_CONSTASCII_USTRINGPARAM macro 7
On Tue, 2010-11-02 at 18:44 +0100, Gert Faller wrote: Hi, with this one, module 'impress' should be rather clean of that. Heh, good, liked the ? : rework to keep me pacified :-). Thanks for this. As an aside, stylistically I'd prefer rtl::OUString sFoo(RTL_CONSTASCII_USTRINGPARAM(apple)); over rtl::OUString sFoo(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(apple))); or rtl::OUString sFoo = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(apple)); even though they're all exactly equivalent, shorter text and more direct, so I modified a few of those in passing while committing this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Easy Hack: Don't draw caret when visual formula editor looses focus
Hi Luke, I thought I'd try one of the visual formula editor easy hacks Great... Your patch looks fine to me... And works very well too! I've applied and pushed your patch to the master branch (commit 8137918224bb). And removed the item from the easy hacks page on the wiki. This one seemed the easiest of the three there. Hope it's okay. More than okay: Great! Issues are here to be fixed - not buried in a bug tracker... I noticed that you've found and updated the todo list (thanks, btw)... This means that you know where to find inspiration for more challenging visual formula editor tasks, should you be interested... (just, drop me an e-mail, if you are). I started the visual formula editor feature during GSoC, so if you want to work on it or have questions, you're most welcome to e-mail me or ping me on IRC... (I'm also available if you need some help getting started with the codebase). Again, thanks for the patch - that's one item off the todo :) -- Regards Jonas Finnemann Jensen. On Mon, Nov 1, 2010 at 23:04, Luke Dixon 6b8b4...@gmail.com wrote: Hello, I thought I'd try one of the visual formula editor easy hacks, as Michael had recommended. This one seemed the easiest of the three there. Hope it's okay. Regards, Luke ___ 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] [PATCH] Easy Hacks : Use RTL_CONSTASCII_USTRINGPARAM macro 6
On Tue, 2010-11-02 at 17:31 +0100, Gert Faller wrote: Hi, some more in impress Pushed, thanks for this again. Sure beats doing it myself :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Some hints about git please...
On Tue, Nov 02, 2010 at 11:02:56PM +0100, Gert Faller gertfal...@aliceadsl.fr wrote: 1) I update the 'clone' directory often. No problem with that. 2) I've read that when updating 'clone', 'bin/g' must be run. I don't find any 'g' in ./bin/. 3) I don't know how to update easily the source in 'build/libreoffice-3.2.99.2' 4) I edit code in 'clone/module' and 'git diff' from there but, for building, I have to go to 'build/libreoffice-3.2.99.2/submodule' where I have done a local git, modify the patch (paths are too long in it eg : a/module/submodule -- a/submodule), 'apply' it, 'build', 'apply -R', and if it's ok, get back to clone/module and undo my work (with the editor or with 'apply -R') There must be an other way less tedious... http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/1133 Have you seen this thread? Basically if you want to contribute, not just build, then the best is to build in rawbuild, then you can easily test your changes. pgpPpZ9p8ZPdA.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
