As discussed in the bug report. I changed all occurrences, not only the one in the Calc menu.
Change-Id: Ia652cb10ec0123b0a79a719dda59e6d2f54f0680
Reviewed-on: https://gerrit.libreoffice.org/6123
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
... by replacing gb_Rdb_install with a separate constructor so the right
target can be registered at the module. There is still an ugly special
case for the ure/services.
Change-Id: I81c004143f201aaf38daca99819888313ee24f49
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
Don't mess with encoding in Logger.log, since sys.stdout.write()
accepts str (in python3) and both str/unicode (in python2) anyway.
Change-Id: Ib0339b7fd882a7654cc24c38efdaf67f519663ff
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
access to libreoffice objects ( and methods/properties of those objects )
from VB all goes through the ole automation bridge. There has been a long
standing issue where the bridge falls over trying to access methods of the
scripting framework MasterScriptProvider object.
Change-Id: I3b9391286e1030bef2a12d6e546a5c47a4f68edb
i.e. I see the bug in our built-in python3 3.3.0 but not in my system python
3.3.2 and there's a raft of email related bug fixes in the 3.3.2/3.3.1
python Changelog
Change-Id: I257770cd0ec41fc3b2f2a638009b075b9a2f325f
through environment vars
Set the log level with the environment variable "PYSCRIPT_LOG_LEVEL"
"DEBUG" (for debugging)
"ERROR" (show errors only)
"NONE" (or anything else) (for production) is the default
and the log output type with the enviroment variable "PYSCRIPT_LOG_STDOUT"
"0" (log output to user/Scripts/python/log.txt)
"1" (or anything else) (log output to stdout)
Patch by: Tsutomu Uchino <hanya.runo@gmail.com>
Review by: Herbert Durr <hdu@apache.org>
Note: Commit message edited by ASF infra team to work around a known issue with the
ASF svn install (not an issue with svn) and UTF-8 handling. This is a temporary
issue that we hope to resolve soon.
(cherry picked from commit 9dc7f72febe9d294304f70cc7b9cdeab1c67dc8b)
Change-Id: I099c8b3f812559c380078f63b692c83fdc811e33
This reverts commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce6708f0e8677dba9cc92e1479a44086 "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d4a6dcac28801cde82a211fb7e30654 again.
I wasn't able to revert without also reverting
be50ad28f5bbdaeff527f646481ce263843c2401 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8fda2a5848e11063028bf44d72f85431
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61b9cabceb9767fad87cd5822b300452
"Fix exception specifications," 2ce6828bbbf6ba181bb2276adeec279e74151ef6 "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce6708f0e8677dba9cc92e1479a44086
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
...in commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654,
"Convert awt::UnoControlDialogModel to new style"
I added an attribute "ResourceResolver" because some of the client
code was setting it using the property interface.
It turns out that this was a bad idea because the "ResourceResolver"
property is doing some very interesting stuff, so revert that part
of the change.
Change-Id: I62b890e60164e005867ced49c3e407a49ed09441
Reviewed-on: https://gerrit.libreoffice.org/4013
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
Original author: Tsutomu Uchino <hanya.runo at gmail.com>
(cherry picked from commit 5de5fd495d7cdad852d1631941ae03ec213f93b7)
Change-Id: Iaa0aa8b1dd6a326cd738f2e296a1b5ecdc379c65
