RFC: command shell
Hi folks, just an idea I'd find quite productive: builtin command shell. Quite often I have to spend quite a lot time for looking through menus and dialogs to find the right commands - often for quite trivial things. (not just in LO, but gui-driven applications in general, eg. gimp). I'm a traditional unix gui, and like to have some shell where I can quickly type in command (w/ tab-completion, maybe even scripting small functions). Does anybody remember 'good old' AutoCAD (from early 90th) ? It practically was command/shell driven, and the GUI just called commands or added parameters (eg. selections, positions, etc) to the command line. Another, IMHO, good concept is the Oberon Operating System. The essential concepts here are: * everything is coded in modules (similar to pascal units) * public (non-function) procedures without parameters can be called as commands. (the individual commands then need to fetch their parameters from global states, like selections cursor position, text behind the command, etc) * in a simple case, you just write down the command in an editor and hit it with the middle button * more intelligent objects (eg. elems - active objects within the floating text, or the Gadgets in the Oberon3 system) just call certain commands the usual way. I'm just imagining an LO with similar capabilitites. Perhaps it could look like this: * an (optional) terminal window with status information (eg. cursor position, current text attributes, etc, etc) and an command line. * when you start typing an command that requires additional data (eg. text range or positions), they can be automatically be filled in by the GUI (eg. when selecting some piece of text) * addressable objects (eg. filenames, windows, text sections, etc) are supported by tab-completable * GUI actions (eg. browsing through menus, or changing something via dialog boxes) show the corresponding commands in the terminal What do you think about this idea ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Mobile: +49 (151) 27565287 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: subsystem for unix based applications on windows
By the way: what about cygwin ? Has anyone already tried it ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Mobile: +49 (151) 27565287 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice ...... Libraries VCL
However - we're moving towards a new way of drawing, and laying out dialogs - which uses a true 'layout' approach - this makes it much easier to draw them (using the 'glade' tool), it also simplifies the code. You can read about that here: https://wiki.documentfoundation.org/Development/WidgetLayout The examples links are broken :( -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Mobile: +49 (151) 27565287 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Anti-aliasing via GPU
On Windows, we use gdiplus, which is notoriously slow. Optionally using WPF there might speed things up a bit, haven't looked any closer yet, though. IIRC, Cairo also runs on win32, so why not using it instead of gdi+ ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Reworking the MSVC-related build options
Hi, Anyway, about killing the --directx-home option, even if that is done, that does not mean having and building against the DirectX SDK (June 2010, or some earlier version) would be mandatory. It would just mean that if the standard DXSDK_DIR environment variable does not exist, then DirectX use is not built, i.e. like --disable-directx. From packager side I'd strongly recommend against such magic logic, as it hurts reproducability. Instead all options affecting the build output should be available as ./configure flags. So my suggestion is: * --enable-/--disable-directx should really force building with/without directx. default enabled is probably the best choice). * only if it's enabled, check for the dxsdk. using an environment variable instead of separate flag is fine, IMHO, as long as that variable is properly documented in ./configure --help output. * when enabled, but no proper dxsdk found, ./configure fails w/ a proper error message cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PATCH Comment translations
This is my first patch! :) Pushing to gerrit is probably the best way to go: http://gerrit.libreoffice.org cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RFC: Generic wrapper for external helpr applications
Hi folks, I'm currently thinking about a generic ways for configuring external helpers, eg. mail client, web browser, etc. (at least on *nix ;-p) For now, many applications (eg. libreoffice) have their own settings, which adds additional code/complexity and requires the user to set it in each single application. Let's imagine some approach which allows it on a system-wide, user-wide, system-wide as well as application-wide basis - how could that look like ? From individual application side, it just wants to know which command to call. It then just would call an universal wrapper, eg. like this: common-helper-app --caller=LibreOffice web-browser --url=http://foo.bar; common-helper-app --caller=LibreOffice web-add-bookmark --url http://www.libreoffice.org; --title LibreOffice Homepage common-helper-app --caller=LibreOffice mail-compose --mailto f...@bar.org --subject Hello world common-helper-app --caller=LibreOffice mail-mailbox --inbox common-helper-app --caller=LibreOffice show-document --auto --file ~/my_image.png common-helper-app --caller=LibreOffice edit-document --auto --file ~/funny_pic.jpg If an application wants to launch an settings dialog for itself, it would call: common-helper-app --caller=LibreOffice configure This 'common-helper-app' could be written in shellscript or whatever language one likes and is provided by the distro. It's now fully up to that command to decide what really to do (it could even consider session specific things like whether to use a graphical or text terminal, use desktop environment specific settings, etc, etc). What do you think about this idea ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Broken commits in our repo
Agreed - we have very significant annotations of specific git hashes left and right to double-check the re-basing work; anything that hinders that process in the next months is incredibly under-appreciated. So - if it's just a few harmless warnings - we should leave it for now. Well, technically, they're quite harmless (normal git operations still work fine), but certain git hosters (at least github) refuse uploading. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GTK theming: oxygen-gtk support broken
Hi, Some time after my commits, which enabled almost fully correct oxygen-gtk support (latest commit was on Jul 8 2012), this support was broken. See screenshots at [1], [2], [3] and [4] for details. Those who hacked on GTK theming support since Jul 8 2012, please have a look at this. If you think it's oxygen-gtk which should be fixed, not libreoffice, please report the particular problems to https://bugs.kde.org (product=Oxygen, component=gtk2-engine). I'll be happy to improve things on oxygen-gtk side. IIRC, this provides KDE look+feel using Gtk, right ? That, IMHO, could count as argument for dropping Qt/KDE vcl. (see my other postings about vcl's/widget toolkits) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build environment for official win32 builds
evidently local file system (NTFS) is rather slow, and process creation is very slow (which is important for any make-based build system). Okay, but this cant explain why cygwin/gcc is so horribly slow compared to msvc (would make both of them slow). Does this also mean kicking out autotools ? LO doesn't use autotools, only autoconf. but of course many bundled external libraries use full autotools. autoconf alone already is evil enough ;-) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: RFC: Generic wrapper for external helpr applications
So there is that xdg-open wrapper which we try to use for sending E-mail / opening composers or opening URLs - at least when we can find it etc. almost what i had in mind. yet missing: * separate action types (eg for differenciating between view and edit) * application-specific settings (eg when mail client should call different helpers than lo) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Broken commits in our repo
Hi folks, while trying to push to github, I've encountered trouble with broken commits: github always runs fsck on post-receive, which fails due to broken commit metadata, and upload will be rejected. See commit 144c7a2e1d711e13422a5c84b34ac33b1d940034 Optimally, we should correct this, but unfortunately that would would conflict existing tags. So how can we do that ? My idea would be writing some git-filter-branch based script which runs through all branches and tags and stores the new ones with some suffix, eg. .FILTERED, additionally add the old ones (which have been rewritten) with suffix .BACKUP. Then we would rename the (active) filtered branches to the official names (eg. master.FILTERED to master) and rebase the unfiltered ones ontop the filtered ones in case of someting was forgotten. The really tricky point is concurrent writes: we need some maintenance downtime window where no new pushes are allowed, so nothing gets lost in the process. When everything's done, we'd do an announcement that people should drop their copies of the tags (and do necessary steps for potentially _local_ tags) and rebase their downstream branches. What do you think about this ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: what's the problem with system cairo ?
Hi, [1] used in: - vcl/Library_vclplug_svp : ifeq ($(GUIBASE),unx) - vcl/Library_vclplug_gtk : ENABLE_GTK - canvas/Library_cairocanvas : ENABLE_CAIRO_CANVAS e.g. for Library_cairocanvas there are also WNT... conditionals in the makefile but configure says: if test $_os = Darwin -o $_os = WINNT; then if test $enable_cairo_canvas = yes; then AC_MSG_ERROR([The cairo canvas should not be used for this platform]) I'd guess the WINNT conditionals are old leftovers, maybe there was some unfinished WINNT-cairo code, maybe limitation of cairo to unix-only was done later. IMHO, we should drop the WINNT-conditionals in cairo as first step. By the way: could we use Gtk on WINNT too ? Not sure about the real implications of that, but from an toplevel architecture view, I'd really prefer that approach to reduce amount of code and complexity. At that point, I'd also raise the question whether we really need different widget toolkits (even on the same platform). Can't we, at least on *nix, choose one crossplatform widget toolkit (I'd personally would prefer Gtk over Qt) and drop all others ? That, IMHO, should reduce the code (source) size and complexity and so maintenance and testing efforts. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Extension Manager: Link to further Extensions
Should we move this link to http://extensions.libreoffice.org/extension-center where our users could search for further extensions? What do you think? Seems plausible to me. By the way: is there some detailed description on the actual (technical) extension deployment process ? From an operators view, I've got a very bad feeling about an application downloading and deploying its own code - instead I'd like to do these things completely via package management. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Daily builds x86_32bits Linux debs from master available again
http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/master/ Cool. Where can I find the corresponding ./debian/* files ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: what's the problem with system cairo ?
Hi, and kde user would have gtk widget when using LO ? Why not ? There are so many gtk-applications running fine in KDE. IMHO (not an KDE-user so didn't check it), the l+f will be just like Qt. Why would you consider that kde and gtk are the same 'platform' and Mac and Windows are not from a UI perspective ? I'm not just looking at the UI only, but the whole operating system. To be more correct, replace kde by qt. On *nix, we've got a pretty clean separation between operating system (kernel+userland tools), display system (wg. X11 or DirectFB, etc), widget toolkits (qt, gtk, wxwin, ...) and (optional) user desktop environments (gnome, kde, xfce, ...). OTOH, Windows doesn't have that clean separation - it's pretty much one big bundle. (MacOSX is somewhere in the middle). The really fine thing on *nix is that it's completely up to the individual application which widget toolkit to choose, and applications normally dont depend on specific desktop environments (well, mostly ;-o). My idea was, consolidating to one crossplatform widget toolkit for *nix as the first step, which should be pretty easy. Later also consolidate the other platforms (not sure how complex that would be). By the way: anybody working on porting the gtk or qt vcl to win32 or mac ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Daily builds x86_32bits Linux debs from master available again
http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/master/ Cool. Where can I find the corresponding ./debian/* files ? http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/master/2012-11-17_13.55.33/ Download the general installer and the lang pack and help pack for e.g. German. Seems we're talking about different things. My question is about the debian control files for generating the .deb packages. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Broken commits in our repo
snip Did a little bit more research: git fsck on a fresh clone spits out long list of broken commit errors: (far more than 50 lines) error in commit edc18425b8c2455c5f0d172126156d90e7c06eb2: invalid author/committer line - missing space before email error in commit 10ab5aa3953d58f3430819a990250741aff25d4e: invalid author/committer line - missing space before email error in commit d76f5aa618f4484b97e9c3846d8fc6d717a306bb: invalid author/committer line - missing space before email error in commit d73c47726d83afc4196c49f6e2cd4d7f2f435637: invalid author/committer line - missing space before email error in commit 41c42f2d98dd50a95268dc1091f6c8e21c3e6667: invalid author/committer line - missing space before email error in commit 436416a6320037855846fce127a0cfa77ac45270: invalid author/committer line - missing space before email error in commit 11ce307732218d59f8132eb0a0fb4b08a4048c3f: invalid author/committer line - missing space before email error in commit 5ad79ff63008de36accc910d474f2e85b4d8d9e1: invalid author/committer line - missing space before email Inspecting a few of them showed up, they're not commits at all, but tree objects. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: what's the problem with system cairo ?
Hi, If you mean if gtk/qt programs run on Windows, yes, they do and look pretty native. The only problem with GTK is that the newest official GTK version for windows is 2.24.10 as they seriously lack Windows developers, so there is no one to make a 3.x version. On Mac, GTK was really buggy, can't check if that is already fixed as I don't have access to a Mac anymore. hmm, thats sad. how's the situation w/ other toolkits, eg. qt ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: visualize module dependencies
modules_dep utility can produce graphviz output now (thank you Norbert for not writing it in perl ;-). This command generates the dependency graph of all LO modules: find $SRC_DIR -name build.lst | sed 's/prj.*//' | xargs $DEV_TOOLS_DIR/modules_dep/modules_dep.bin -s -c solenv -g | grep -v tail_build | dot -Tpng -o lo_modules.png Deep pink are modules that still not migrated to gbuild: http://ostrovsky.org/libo/lo_modules.png cool. does that also work for external dependencies ? and perhaps also basen on the current build onfiguration ? this could be helpful to find out whether certain libs are unnecessarily linked in. for example, a few days ago, i was working on --enable-dbus+friends and found out that this is just an dependency for other optional features and is completely useless if they're switched off. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Daily builds x86_32bits Linux debs from master available again
http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/master/ Cool. Where can I find the corresponding ./debian/* files ? http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/master/2012-11-17_13.55.33/ Download the general installer and the lang pack and help pack for e.g. German. Seems we're talking about different things. My question is about the debian control files for generating the .deb packages. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[PATCH] autogen.sh: support for default distro config
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1096 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/96/1096/1 autogen.sh: support for default distro config Always try to read distro-configs/default.conf (if existing) before any option parsing. That way, downstreams (distros, etc) can just place there site config into the tree without having to pass any additional options to autogen.sh, and even automatic invocations will always have the right parameters. Change-Id: Ic5bf68adc719476d374cf03e31e054b69c931b72 --- M autogen.sh 1 file changed, 6 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1096 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ic5bf68adc719476d374cf03e31e054b69c931b72 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Fixed previous commit on autogen.sh default config
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1097 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/97/1097/1 Fixed previous commit on autogen.sh default config Change-Id: I29cc49dcc284b462ac29d0d040e331f3e6d08e74 --- M autogen.sh 1 file changed, 1 insertion(+), 2 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1097 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I29cc49dcc284b462ac29d0d040e331f3e6d08e74 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
external build directory
Hi folks, is it possible to let lo put all build outputs and temporary files to some different directory (eg. on tmpfs, etc) ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: easyhack: could someone translate these comments from German ?
- Ursprüngliche Mail - Von: Lior Kaplan kaplanl...@gmail.com An: libreoffice@lists.freedesktop.org Gesendet: Samstag, 17. November 2012 17:51:35 Betreff: easyhack: could someone translate these comments from German ? See http://cgit.freedesktop.org/libreoffice/core/tree/svtools/inc/svtools/ctrlbox.hxx? https://gerrit.libreoffice.org/1098 Thanks (: ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] translated german comments to english
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1098 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/98/1098/1 translated german comments to english Change-Id: I4df4f471578f78f586d4a69b5eb7561415f3994b --- M svtools/inc/svtools/ctrlbox.hxx 1 file changed, 51 insertions(+), 52 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1098 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I4df4f471578f78f586d4a69b5eb7561415f3994b Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Xlib import via generic pkg-config
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1099 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/99/1099/1 Xlib import via generic pkg-config Generic importing Xlib+friends via pkg-config, instead of scanning through a list of directories. This is very helpful for non-standard installation pathes and crosscompiling, as the generic pkg-config infrastructure will handle it all. Also dropping the obsolete bundled Xext headers. Change-Id: I6ee381030ff9f1d2d83062a17ab55ad3d847a4c6 --- M Makefile.top M Module_tail_build.mk M RepositoryExternal.mk M RepositoryModule_ooo.mk M configure.ac M vcl/Library_vcl.mk M vcl/prj/build.lst D x11_extensions/Makefile D x11_extensions/Module_x11_extensions.mk D x11_extensions/Package_inc.mk D x11_extensions/README D x11_extensions/inc/Xrandr.h D x11_extensions/inc/Xrender.h D x11_extensions/inc/randr.h D x11_extensions/inc/randrproto.h D x11_extensions/inc/render.h D x11_extensions/inc/renderproto.h D x11_extensions/inc/shape.h D x11_extensions/inc/shapeconst.h D x11_extensions/prj/build.lst D x11_extensions/prj/d.lst 21 files changed, 6 insertions(+), 2,222 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1099 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I6ee381030ff9f1d2d83062a17ab55ad3d847a4c6 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Platform ports vs. multiplatform
Hi, yes, but at least according to debian/ubuntu build rules, that doenst seem to be enough. (debian's rule file is over 3k LOC) Ah - that does seem a tad unfortunate. I'm sure there are lots of good things in debian's rules file that we could fold into the core and make easier for distributors in an incremental fashion. Having not read the file - I've no concrete ideas there :-) but ... at least looking at how some of our .spec files re-order and re-group the scp2 break-down to get the packaging prettier lots could be improved in that bit alone. One thing we, IMHO, should do is splitting the whole thing into smaller parts, eg. building extensions or helpcontent out of tree, moving them to their completely own packages. That would make packager's life much easier. Another front is 3rdparty libraries. Optimally, as a packager, you want it to get its deps entirely from the system (or sysroot) - without having to tweak a lot of parameters - and _never_ let it download anything. Packaging then needs to run entirely through the distro's machinery. OTOH we've got platforms that don't know the concept of distros and package management/repositories. My approach to this is: having a separate 'workspace' system for handling all the things that usually distro build machines would do. Esentially rolling an own micro-distro (or multiple ones for several platforms). Such an micro-distro, eg. for win32/cygwin, would do things like: * proper toolchain setup, at least check if everything's correct, and guide the user through the setup (if it can't be done automatically) * deploy cygwin build environment and maybe pull in required packages * build missing dependencies (not yet in cygwin repos) and deploy them into the build environment * maybe provide some user friendly buildtime configuration (perhaps something windows-friendly counterpart of linux kernel's 'make menuconfig' ?) * build lo itself * create deployable packages (cygwin, msi, ...) install program (which maybe would just be a little wrapper around msi) Similarily, there could be such an 'workspace' for Debian+friends, which: * makes sure all required packages are installed (via apt-get calls) * builds the missing 3rdparty libs (that aren't in debian yet) into their own prefix (eg. /usr/lib/libreoffice/depend/), packaging to something like 'libreoffice-libraries', adding it to local aptrepo * drive the package build, w/ --with-system-*, adding proper pkg-config pathes and build proper deb packages * runs all package builds via pbuilder+friends --disable-epm ? I'm talking about dropping it completely in my branch. By the way: what is this actually used for ? Not sure about the other distros, but Debian+friends dont seem to use it. Oh; EPM is used to build the generic cross-distribution packages that we ship for Linux. Well, to have it really generic, you'll need to link statically against all libraries normally found on operating systems, down to libc. This leads to an huge increase in diskspace and memory consumption. Another drawback is that bugfixes (esp. security-related!) coming from their distro. I'd consider that as a workaround if you _really_ need very recent versions that aren't distro-packaged yet. At this point, I'd seriously raise the question why distros lag behind so far that people get interested in such an cross-dist package. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: reorganizing ./configure --help output ?
Hi, On Thu, 2012-11-15 at 22:16 +0100, Enrico Weigelt wrote: is it possible to reorganize the ./configure help options into several groups for easier reading ? Grief - the re-ordering is done by changing the order of the options in configure.in. That tends to generate -huge- patches and screws with the interdependency of various options (if we're not quite careful). Well, if you're just concerned about patch size - we could do that in smaller steps. Option declarations (AC_ARG_ENABLE[]+friends calls) already seem to be pretty separated from actual option handling, so this, IMHO shouldn't be such a big deal. The more interesting question to me right now is: how to add the separate section headers, so configure --help would look like: --enable-some-foo blaah MacOS-X target specific options --with-macosx-sdk . . cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build environment for official win32 builds
in addition to above points also there are also open questions around how we would run unit tests in a MinGW cross-compilation environment and how well gdb works on Windows; the MSVC C++ debugger is really quite good. What about native compiling (not crosscompile) on win32 using gcc ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build environment for official win32 builds
Hi, There are also some features in the code that don't compile with MinGW. They use API that MinGW does not provide headers for etc. Ok. Is there already some list of known issues ? Let me also point out that we definitely do not want to build *locally* on Windows with GCC (MinGW). MinGW makes sense to us only for cross-compilation. If one wants to build locally on a Windows machine, use MSVC. Why so ? Note that when we say MinGW, we actually mean mingw-w64, a fork of MinGW that provides a more complete set of headers and import libraries for various Windows APIs. (Despite the w64 in the name, they do provide a tool-chain producing 32-bit code, too.) Okay. Does it run under win32/cygwin ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build environment for official win32 builds
Hi, Anything is possible in LibreOffice :-) having said that - personally I'd want to see that adding support for this doesn't tangle the build system too badly - particularly wrt. confusing our mingw cross-compilation support. I have to admit, I haven't tried it yet, but _assuming_ it is just a normal GNU toolchain that just happens to produce win32 binaries, it should make things easier in the long run. Of course, we need to cleanly differentiate between normal and crosscompiling (IOW: not assuming crosscompile on mingw32 target). The real question is - what is the deliverable here ? building on windows under cygwin is -horribly- slow - if we can use the same compiler to cross-compile from Linux (as we can) and build around 50x faster - why would we want to do work maintenance to keep that going ? :-) Oh! Do you know where that slowdown is coming from ? But of course, if you want to do that port, maintain it, and you plan to ship binaries of your own from it (which will be bigger and slower than the official ones) Why so ? Is GCC on win32 _so_ bad compared to MSVC ? Hopefully (when fully finished) the move to gnumake will at least strip out one layer of (dmake) grief that makes such things more painful than they really need to be. Does this also mean kicking out autotools ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-users] - Scalc.java ported to C++ , uses DocumentLoader
Is there any secure place to put this code for the benefit of users ? Wiki or being bundled with examples ? I posted this to users list and Tom Davies kindly suggested I try the DEV list. Maybe push it to gerrit for review ? https://gerrit.libreoffice.org/ cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fixed java classpath parameter (required for gcj)
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1073 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/73/1073/1 fixed java classpath parameter (required for gcj) Change-Id: I0ad426a8791ab514978e01914f9f797b45d0c79a --- M solenv/gbuild/JavaClassSet.mk M solenv/gbuild/JunitTest.mk 2 files changed, 2 insertions(+), 2 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1073 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I0ad426a8791ab514978e01914f9f797b45d0c79a Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] dropped obsolete test code
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1077 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/77/1077/1 dropped obsolete test code Change-Id: I2ec5c4b9c281c0afde2fdeb899418c2f9d199607 --- M sc/qa/extras/sccellrangeobj.cxx M sc/qa/extras/scdatapilotfieldobj.cxx M sc/qa/extras/scdatapilottableobj.cxx M sc/qa/unit/subsequent_filters-test.cxx M test/Library_subsequenttest.mk M test/Package_inc.mk M test/inc/test/beans/xpropertyset.hxx D test/inc/test/container/xelementaccess.hxx D test/inc/test/container/xindexaccess.hxx D test/inc/test/container/xnamereplace.hxx M test/inc/test/sheet/xcellrangesquery.hxx M test/inc/test/sheet/xdatapilotdescriptor.hxx M test/inc/test/sheet/xdatapilotfieldgrouping.hxx D test/inc/test/sheet/xspreadsheetdocument.hxx M test/source/beans/xpropertyset.cxx D test/source/container/xelementaccess.cxx D test/source/container/xindexaccess.cxx D test/source/container/xnamereplace.cxx M test/source/sheet/xcellrangesquery.cxx M test/source/sheet/xdatapilotdescriptor.cxx M test/source/sheet/xdatapilotfieldgrouping.cxx D test/source/sheet/xspreadsheetdocument.cxx M unusedcode.easy 23 files changed, 0 insertions(+), 582 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1077 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I2ec5c4b9c281c0afde2fdeb899418c2f9d199607 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] dropped dead code from svg
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1078 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/78/1078/1 dropped dead code from svg Change-Id: I73244d54f182f44c08a942dee95ff11b53a24f5a --- M svgio/inc/svgio/svgreader/svgdocument.hxx M svgio/inc/svgio/svgreader/svgstyleattributes.hxx M svgio/source/svgreader/svgdocument.cxx M svgio/source/svgreader/svgstyleattributes.cxx M svgio/source/svgreader/svgtextpathnode.cxx M svtools/inc/svtools/treelist.hxx M svtools/source/contnr/treelist.cxx M unusedcode.easy 8 files changed, 0 insertions(+), 48 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1078 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I73244d54f182f44c08a942dee95ff11b53a24f5a Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] ==== SUBMITTED ====
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1079 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/79/1079/1 SUBMITTED Change-Id: Ia47e4b1959d9c8fdb8f6b0a82038c7ddee3b938b --- 0 files changed, 0 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1079 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ia47e4b1959d9c8fdb8f6b0a82038c7ddee3b938b Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Adding the browser to Libreoffice
Unfortunately my first response is NO. ACK. Different users prefer differnt browsers, so why adding yet another one that many people wouldn't like anyways ? Maybe there are some options for improving browser integration, but that's a whole different topic, IMHO. Instead, in an other way, I'd rather to put such an effort in improving Libreoffice by put it into a browser, What would be the practical benefit of that ? Or are you talking about making lo an web application ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Adding the browser to Libreoffice
i wonder why people say that an office suite needs to have an email client: is that only because Microsoft Office includes one? Actually, I wonder the same thing. Similar on the mozilla front: why should a browser include an calendar ? I, personally, one tool for one job - simple and small - and then integrating them together via generic interfaces (so the individual tools can be easily replaced). surely nobody actually wants to embed a mail client into a Writer document as an OLE object? Hah, that would be a funny thing ;-) By the way: do we already have an integrated tetris and solitare ? ;-) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [tdf-discuss] Adding the browser to Libreoffice
Hi, +1 to Tim below. IMHO if we're on the topic of adding another program to LibreOffice - Project Management (PM) should be considered over adding yet another open source Browser. I'm reasonably certain there are not enough resources at the moment to do this - at least not without partnering/forking one of the existing open source PM projects. Which featureset would you like to see in such an extension ? Wouldn't it be easier to just pick some existing solution (eg. we're using Redmine) instead ? From what I see in the industry (mid- and large-size enterprises), the big trend is going to web-based applications. Several of our customers even dropped their local MUA's (in that case: Outlook) completely after we've replaced their Exchange by Zimbra. So, it seems that business customers tend to prefer web applications (possibly with customer-specific integrations to 3rdparty systems) over local applications. In general, I'd point out two argumentation lines against adding fundamentally new functionalily of such kind: a) featureset and choice Different users have different requirements (the ugliest of all is ERP world, where everybody seems to have its own or at least heavily cutomized system). Therefore we should give people the choice and instead add some optional integrations via generic interfaces. (eg. people that like to use lo as a dashboard, they could use some extension that display interesting informations like ticket lists, timelines, etc from an prjm-system, or a list of new mails in some kind of lo-integrated xbiff counterpart) b) economical Developing such new functionality from start up would essentially duplicate existing applications, require a lot of resources and expertise, which is most likely is not availble to lo project. By the way: in case you're going to work on some integration to systems like redmine, plone, openerp, zimbra, just let me know, I'd like to join in. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fixed java classpath parameter (required for gcj)
By the way, Enrico, could you please send the list a blanket license statement that you provide your patches under the LGPL3 and MPL2 license? (Otherwise we will have to revert them.) Something like: All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. All of my past and future contributions to LibreOffice, uploaded to gerrit.libreoffice.org, may be licensed under the MPL/LGPLv3+ dual license. Contributions to 3rdparty packages bundled in LibreOffice are licensed under the license terms of the according package. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Build environment for official win32 builds
Hi folks, I'd like to setup an win32 build environment which reproduces the official win32 builds for verifying my patches. What do I need for that ? thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Platform ports vs. multiplatform
Hi folks, I'm currently working on an downstream fork (means: regularily rebased) for an GNU/Linux-only version. The idea is: make it trivial to build/install on common GNU/Linux distros, so no additional magic is required for packaging. Major points: * drop all bundled libraries that are already available on mainline distros * simplify the import logic (eg. use pkg-config whereever possible) * drop all specific logic for other platforms * drop EPM stuff Once that's working, I'd like to extend it to other platforms (eg. win32). Yet to be explored: can/should cygwin,ming32,android be treated as GNU favours or be separated platforms. If anyone's interested in this, just let me know. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Thu, 2012-11-15 at 01:47 -0800, Olivier R. wrote: Michael Meeks-2 wrote + upgrade bundled python to 3.0 3.0 ? I assume there is a typo here. Yes - certainly a typo :-) We'll go for the best 3.x based python we By the way: will pyton-3.2/3.3 be an requirement or will 2.x still work ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
removing unused functions
Hi folks, I'm currently working on removing unused functions (mentioned in unused.easy). Should I do it one by one with separate commits or in one big commit ? An big commit would make it easier/quicker for me (as I dont need so many rebuilds), but perhaps could make review a bit harder. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] ==== SUBMITTED ====
I have submitted a patch for review: https://gerrit.libreoffice.org/1079 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/79/1079/1 SUBMITTED Change-Id: Ia47e4b1959d9c8fdb8f6b0a82038c7ddee3b938b --- 0 files changed, 0 insertions(+), 0 deletions(-) sorry, that was an accident ;-o can I drop it from gerrit somehow ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
==== SUBMITTED ====
Enrico Weigelt, metux IT service has abandoned this change. Change subject: SUBMITTED .. Patch Set 1: Abandoned accidentially pushed a local hacking branch ;-o -- To view, visit https://gerrit.libreoffice.org/1079 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Ia47e4b1959d9c8fdb8f6b0a82038c7ddee3b938b Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com Gerrit-Reviewer: Christian Lohmaier lohmaier+libreoff...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] unusedcode exclude file: symbols known to be required
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1084 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/84/1084/1 unusedcode exclude file: symbols known to be required The file unused.easy contains a lot of symbols which are known to be required, even they're currently not referenced by anyone. Change-Id: I048c1656b240f7d601e4c99b8d9c4969b3954c87 --- M unusedcode.README A unusedcode.exclude 2 files changed, 28 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1084 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I048c1656b240f7d601e4c99b8d9c4969b3954c87 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
updated .gitignore
Enrico Weigelt, metux IT service has abandoned this change. Change subject: updated .gitignore .. Patch Set 2: Abandoned not required at all, had just artifacts from submodule migration. -- To view, visit https://gerrit.libreoffice.org/1062 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Iad05efb16a0299b8e794bf93107b0e5e6396a6c0 Gerrit-PatchSet: 2 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com Gerrit-Reviewer: Eike Rathke er...@redhat.com Gerrit-Reviewer: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com Gerrit-Reviewer: Stephan Bergmann sberg...@redhat.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Platform ports vs. multiplatform
Hi, * drop all bundled libraries that are already available on mainline distros note that most of that can be handled by a proper file in ./distro-config/. yes, but at least according to debian/ubuntu build rules, that doenst seem to be enough. (debian's rule file is over 3k LOC) * simplify the import logic (eg. use pkg-config whereever possible) * drop all specific logic for other platforms what is the benefit of that, except creating busy work for you ? For now, at least some hacking fun, learning a bit more about the lo internals and maybe in the end a much simpler build system. The whole operation gets more intersting when done for multiple platforms. I'll start w/ win32 once i'm done w/ gnu/linux. * drop EPM stuff --disable-epm ? I'm talking about dropping it completely in my branch. By the way: what is this actually used for ? Not sure about the other distros, but Debian+friends dont seem to use it. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: --with-system-mozilla-headers - --with-system-npapi-headers
Hi, Attention please, as http://cgit.freedesktop.org/libreoffice/core/commit/?id=13ef9dcc206d30ebd4d63afb186d379dc849b36c Rename 'Mozilla headers' to 'NPAPI headers' (incl. configure option name) just renamed a configure option, for better or worse. great thing, makes it a little bit more clear. By the way: what's the --enable-mozilla option actuall for ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: dropped obsolete test code
If the calc maintainers want these - we should keep them around of course even if they're not used. Okay. can we exclude them from the unused.easy file ? -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] renamed --enable-packagekit to --enable-font-autoinstall
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1085 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/85/1085/1 renamed --enable-packagekit to --enable-font-autoinstall The configure option --enable-packagekit is quite a bit misleading, doesn't tell what it's actually for. Therefore renaming the option. Also, semantics have changed: * when omitted (=auto), it's automatically enabled when dbus is activated. * when enabled explicitly, but dbus is disabled (or not available on the target platform), bail out with error message Change-Id: Idb951032a0de33d712cb1551a5696d88ebd29373 --- M RepositoryExternal.mk M config_host.mk.in M configure.ac M vcl/generic/fontmanager/fontconfig.cxx 4 files changed, 43 insertions(+), 27 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1085 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Idb951032a0de33d712cb1551a5696d88ebd29373 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] renamed --enable-bluetooth to --enable-sdremote-bluetooth
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1086 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/86/1086/1 renamed --enable-bluetooth to --enable-sdremote-bluetooth The current configure option --enable-bluetooth is a bit misleading, it doesn't really tell what it's actually for. Therefore renamed it, so it's more clear that it's an sdremote backend using bluetooth. Change-Id: Ia8b46ee001ea112b80521baa502dcab2bb7e83aa --- M config_host.mk.in M configure.ac M sd/Library_sd.mk M sd/Library_sdui.mk M sd/source/ui/dlg/RemoteDialog.cxx M sd/source/ui/remotecontrol/Server.cxx 6 files changed, 21 insertions(+), 21 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1086 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ia8b46ee001ea112b80521baa502dcab2bb7e83aa Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: --with-system-mozilla-headers - --with-system-npapi-headers
By the way: what's the --enable-mozilla option actuall for ? see http://lists.freedesktop.org/archives/libreoffice/2012-November/041107.html So, iirc, this switch affects nsplugin as well as moz addressbook ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
reorganizing ./configure --help output ?
Hi folks, is it possible to reorganize the ./configure help options into several groups for easier reading ? For example, things like * --enable-verbose / --disable-verbose * --disable-zenity * --enable-icecream * --disable-ccache could go into its own group, eg. Build process tuning, * --enable-bogus-pkg-config * --with-macosx-sdk * --with-macosx-version-min-required * --with-macosx-version-max-allowed could go to group MacOS specific What do you think about this ? How can this be done (I've already seen it in other packages, but unfortunately dont remember where it was ;-o). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Removed splash screen
Enrico Weigelt, metux IT service has abandoned this change. Change subject: Removed splash screen .. Patch Set 2: Abandoned -- To view, visit https://gerrit.libreoffice.org/1063 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Ia6a67e1fd5b36588eab2c93be13156843b19ba53 Gerrit-PatchSet: 2 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com Gerrit-Reviewer: Björn Michaelsen bjoern.michael...@canonical.com Gerrit-Reviewer: Eike Rathke er...@redhat.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
fixed java classpath parameter (required for gcj)
Enrico Weigelt, metux IT service has abandoned this change. Change subject: fixed java classpath parameter (required for gcj) .. Patch Set 1: Abandoned -- To view, visit https://gerrit.libreoffice.org/1061 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I9a2832cef534a289040d27ad2a84a0152fefad43 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com Gerrit-Reviewer: Michael Stahl mst...@redhat.com Gerrit-Reviewer: Tor Lillqvist t...@iki.fi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] dropped obsolete --with-system-gettext configure option
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1060 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/60/1060/1 dropped obsolete --with-system-gettext configure option Change-Id: Ia46cb802d40bb1ba199cf937f332c4b343bc22e9 --- M README.cross M configure.ac M distro-configs/LibreOfficeMinGW.conf 3 files changed, 0 insertions(+), 7 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1060 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ia46cb802d40bb1ba199cf937f332c4b343bc22e9 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] updated .gitignore
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1062 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/62/1062/1 updated .gitignore Change-Id: Iad05efb16a0299b8e794bf93107b0e5e6396a6c0 --- M .gitignore 1 file changed, 115 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1062 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Iad05efb16a0299b8e794bf93107b0e5e6396a6c0 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fixed java classpath parameter (required for gcj)
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1061 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/61/1061/1 fixed java classpath parameter (required for gcj) Using long parameter, instead of short one. Change-Id: I9a2832cef534a289040d27ad2a84a0152fefad43 --- M solenv/gbuild/JavaClassSet.mk M solenv/gbuild/JunitTest.mk 2 files changed, 2 insertions(+), 2 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1061 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I9a2832cef534a289040d27ad2a84a0152fefad43 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Removed splash screen
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1063 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/63/1063/1 Removed splash screen The splash screen doesnt seem to be actually useful, more like an marketing artifact from ancient commercial times, with tendencies of just disturbing the user experience ;-P OTOH it adds additional complexity to application startup and doens't actually make debugging easier. Change-Id: Ia6a67e1fd5b36588eab2c93be13156843b19ba53 --- M Repository.mk M bin/distro-install-file-lists M configure.ac D desktop/Executable_oosplash.mk D desktop/Library_spl.mk D desktop/Library_spl_unx.mk M desktop/Module_desktop.mk M desktop/inc/app.hxx M desktop/scripts/soffice.sh M desktop/source/app/app.cxx M desktop/source/app/check_ext_deps.cxx M desktop/source/app/cmdlineargs.cxx M desktop/source/app/cmdlineargs.hxx D desktop/source/splash/services_spl.cxx D desktop/source/splash/spl.component D desktop/source/splash/splash.cxx D desktop/source/splash/splash.hxx M desktop/unx/source/args.c M desktop/unx/source/args.h D desktop/unx/source/splashx.c D desktop/unx/source/splashx.h M desktop/unx/source/start.c D desktop/unx/splash/exports.map D desktop/unx/splash/splash.component D desktop/unx/splash/unxsplash.cxx D desktop/unx/splash/unxsplash.hxx M distro-configs/LibreOfficeLinux.conf M distro-configs/LibreOfficeOpenBSD.conf M postprocess/packcomponents/makefile.mk M scp2/source/ooo/common_brand.scp M scp2/source/ooo/file_library_ooo.scp M sysui/desktop/man/libreoffice.1 M vcl/Library_vcl.mk M vcl/Package_inc.mk M vcl/generic/app/gensys.cxx M vcl/inc/svdata.hxx D vcl/inc/vcl/introwin.hxx M vcl/source/window/dialog.cxx D vcl/source/window/introwin.cxx M vcl/source/window/window.cxx M vcl/unx/x11/x11sys.cxx M vcl/win/source/app/salinfo.cxx M vcl/win/source/window/salframe.cxx 43 files changed, 22 insertions(+), 2,600 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1063 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ia6a67e1fd5b36588eab2c93be13156843b19ba53 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] source file modes fix
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1065 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/65/1065/1 source file modes fix Change-Id: I8975f26f205ba33044285729da54e0210f872fcb --- M cli_ure/source/climaker/climaker_app.cxx M cli_ure/source/climaker/climaker_emit.cxx M connectivity/qa/connectivity/ado/DriverTest.cxx M desktop/source/app/sofficemain.cxx M svtools/source/uno/svtxgridcontrol.hxx M vcl/generic/fontmanager/afm_keyword_list 6 files changed, 0 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1065 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I8975f26f205ba33044285729da54e0210f872fcb Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] dropped unused method: FileStream::open
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1072 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/72/1072/1 dropped unused method: FileStream::open Change-Id: I3e6c1341666fddcfd1bd272a0943ca1de3e5d629 --- M codemaker/inc/codemaker/global.hxx M codemaker/source/codemaker/global.cxx M unusedcode.easy 3 files changed, 0 insertions(+), 14 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1072 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I3e6c1341666fddcfd1bd272a0943ca1de3e5d629 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Enrico Weigelt, metux IT service metuxitserv...@googlemail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: using syslog instead of console for messages
while in headless mode i'd like to have messages delivered to syslog instead of stderr / stdout, looking at the SAL_* implementation it looks like what i want is to substitute the std::fputs in osl/all/log.cxx::log() with syslog() plus some map between these levels and syslog ones. Is that ok? Why not just calling the application with 21 | logger -t libo in this case ? Also does libo makes sense as message prefix? thanks, riccardo ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Using compiler plugins
Hi, as a followup to building LO with the Clang compiler, I tried to have a look at writing plugins for it during the last SUSE Hackweek. It turned out to be quite straightforward, after one gets into it, and it seems to open possibilities to do quite powerful things. snip Sounds interesting. But let me get that straigt: you're using the compiler plugins just as refactoring/analysis tools, not for the actual production build, right ? Because otherwise that's likely to introduce problems for build/package engineering, especially when it comes to isolated builds and cross- compiling. By the way: crosscompiling, optimally, should be a standard test run in tinderbox builds. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
most likely the versions on the system are too old for LO. e.g. we depend on the mdds 0.6 that was just released a week ago. I could provide packages for Ubuntu and Debian, if someone likes. Just drop me a note (personally, not through the list). and hsqldb and saxon are special cases where we almost always have to use the internal ones; maybe --with-system-libs should not affect those... in which way are they special ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build time optimization
Hi, Then next step would be not to build external libs during LO build. There is a magic option: --with-system-libs. If you try this option on debian based systems (x86_64) you would probably end up with clucene dependency not met error. ACK. While hacking on dropping all bundled 3rdparty libs, I faced similar problems. My workaround for now is to install all the deps locally (in the user who's running the build) and pass proper pkg-config env variables to ./configure. Just a matter of installing those two available clucene packages? Unfortunately not: as it turns out those packages are hopelessly outdated (2008). Yes, it seems there had been a major rewrite of clucene, and the two versions actually seem to be separate packages (from deployment side) now. I was also considering providing an recent clucene package for ubuntu (just didnt have the time to properly set up the ubuntu build machinery on my side). I'm thinking about another magic configure option, like --with-external-lib-directory=/opt/libo this would install all dependend libs to this directory during first build and this would *survive* the make clean call, so the next time all external lib artifacts would be reused from there. I wouldn't recommend this, as it makes the build machinery even more complex. Better write a small shell script that builds the missing deps (those not already in your distro) to some proper prefix and then calls the LO build machinery with proper parameters (eg. pkg-config search pathes). I've already hacked up a little bit, but not really useful yet. My plan is to package all the yet missing deps for the major distros (in my case: ubuntu) and throw them out of the LO tree entirely. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build time optimization
Hi, It is not that certain that ramdisk on linux really helps. ramdisk eat-up memory that cannot be used for fs-cache... so ramdisk will increase the cache-miss at the kernel level... I've used ramdisks for automatic mass builds on some other projects, and it really helped (IIRC factor 10). But the scenario there was a bit different: much smaller codebases and the machines had a lot of ram (16GB), and i didn't want to keep the actual build output, just know whether it builds at all and certain post-tests succeed. I guess, we only find out if we try ;-o I have not tested ramdisk on Windows, so I do not know how effective it is. On what I remember from certain large enterprise hosting projects, Windows (at least pre Win7) was pretty bad in IO (the OS itself keeps the stores quite busy for certain housekeeping tasks, so at least on short load peaks that was quite unpleasent - no idea if that really matters much in this scenario). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: May I ask questions ? [WAS: On SSL library support]
Well - I'm sorry you feel that way; you're of course welcome to discuss things inside the project, but please use the discuss list for everything not directly related to a code contribution you're working on :-) Hopefully it's not such a bad thing to have different purposes for different lists. Ah, so the development discussions happen on a completely different list (that's not actually well announced), while -dev is only for patches ? Well, how could I miss that obvious part ... ;-o cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
Hi, Due to a license conflict with a project I was working on, I had the task of building LibreOffice without OpenSSL support. which kind of conflict exactly ? I realize that a more appropriate solution would be to conditionally compile the two code paths using WITH_OPENSSL and WITH_NSS after adding configure flags (--with-openssl and --with-nss) so that packagers can select the preferred SSL library. Note that this adds another dimension to the variant space. In this case the new dimension is binary, so the amounts of variants to test is doubled. -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
i don't really get the point of supporting 2 different crypto libraries (given that we don't really offer anything in terms of re-usable libraries ourselves here, we just ship an application that needs crypto stuff done); it just seems to add additional complexity, and bloat to the installation sets, and we have to keep 2 different bundled libraries that do the same thing up to date with security fixes etc. ACK. But then please use it as directly as possible (not yet another wrapper around it again). seems the Fedora project is standardizing on NSS for crypto applications: http://fedoraproject.org/wiki/FedoraCryptoConsolidation Well, typical for a desktop-only distro. I just can't remember anything on a server system that uses the typically-netscape-jabba-sized nss (and I cant imagine why I should ever want that). Just had a look at the source (3.12.9) - they still include several 3rdparty libs (including the fat nspr monster) _in the tree_. Seems they feel great pleasure in making package maintainer's and systems engineer's life harder. I would fully support nss, if they would: #1 get rid of nspr completely #2 drop all bundled 3rdparty libs #3 drop the binary key/cert store in favor of pure filesystem-based approach (just like w/ openssl) #3 split it into separate layers in separate libraries Otherwise it's practical use is limited to pure desktop-only environments. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
On Fri, May 04, 2012 at 03:16:59PM +0200, Enrico Weigelt wrote: Otherwise it's practical use is limited to pure desktop-only environments. Of course, given that LibreOffice is not a desktop application, oh wait... This statement was on Fedora's global consolidation project. Please always keep the context. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW-3-5] more robust way for nss initialization, related fdo#45171
[1] should fix all possible remaining problems around nss initialization. We now fall back to nss initialization without mozilla profile if with profile did not succeed. This might happen if the profile path is invalid or the profile does not exist. I hope that with this fix we are now able to init nss even if everything goes wrong with the mozilla profiles. Hey, wait a second, LO accesses mozilla's private configuration ?! You know why this is a major design problem ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW-3-5] more robust way for nss initialization, related fdo#45171
On Fri, 2012-05-04 at 16:44 +0200, Enrico Weigelt wrote: Hey, wait a second, LO accesses mozilla's private configuration ?! In order to set the certificate directory for nss so that when using the digital signatures feature the user's personal firefox/thunderbird certs can be found to suggest for use. The big problem here is: you're directly relying on the *private* configuration/runtime data of a completely different application. That data was never meant to be shared with anyone. It's even still one of the things blocking a really-multiprocess Mozilla (which these guys are talking about for now about a decade), and it already causes more than enough trouble within Mozilla. If the goal is having a (per-user) global cert pool, why not just inventing some ? Could be a simple as just putting all certs in a proper directory (like found on most distros in /usr/share/ca-certificates). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
Sorry for being tardy to the party here, but one thing that wasnt mentioned was OpenPGP. Could that be considered as an alternative? From what im seeing in the Ubuntu world, they are using it to sign packages, could that be used as an alternative to OpenSSL? ACK. And, btw, xmlsec also has an command line tool that can be called easily. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
May I ask questions ? [WAS: On SSL library support]
The point is, they are not relevant for LibreOffice's goals. In fact, since you're distracting other contributors from LibreOffice goals, they are in practice against LibreOffice goals, so it may happen that ignoring you will be achieved by technical means, Ah, you wanna ban me from the list, just because I ask questions that matter to me, instead of playing the coding monkey for you on issues that dont matter to me ? Fine that we have made that clear now. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: May I ask questions ? [WAS: On SSL library support]
It seems to me, that you contribute a lot of opinionated email, and thus far no useful code. Well, my code base isn't ready for submission yet - I didn't really have a chance to test it, because: a) builds take so long (somewhere in scale of an hour) b) latest master doesnt even compile - for several month now, and I didnt find the time to fix it yet (working on that extremly large tree takes so much time waiting for the machine) c) it's only a spare time project Meanwhile, given the tone in the list, where even asking a few questions is considered as disturbance or confusion of newcomes (whatever that exactly means ;-o) I've completely dropped the whole idea of pushing anything back. I will now continue my trim-down project, without ever caring if the changesets will ever fit into upstream, as you won't ever be interested anyways. I don't work for you, I'm doing that just for fun. If you wanna ban me now, just go on, I don't care anymore. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: rtl::O[U]String::operator== - to rtl::O[U]String::equals
I can't thing of a good reason why that might be ?, so now converted operator== to simply call equals Any reason where there's an separate equals() method at all ? -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
Hi, We should not prefer system libraries if the internal copy has an important fix. The interesting question now is: what qualifies an 'important fix' ? IMHO, when the current stable release is really broken. But: in this case, most likely, the distros will clean up the mess anyways, so again we can relax and let the distros do their job. You see that most system libraries should be safe to use. In addition, distro specific packages has to use system libraries because it oreduces maintenance effort, optimizes build and download size. So, the system libraries are tested and should be tested. Why not use them during development? Exactly. I'd suggest doing development/testing on stable releases of various major distros (whichever individuals prefer). We already prefer some system libraries by default: e.g. glibc, BTW: i remeber, several years ago, Oo even shipped its own copy of glibc and gcc ... ;-o libpng, libjpeg? Where is the edge? That's the important question! 2. official TDF release: + need to use as many internal libraries as possible to be usable on different systems = we could solve it by adding --without-system-bla to distro-configs/*.conf; we have beta/rc phase to find bugs here I would prefer dropping that completely from the main codebase, and instead build an separate meta-build layer. Essentially just a shell script that fetches the libs, builds and installs them to some suiteable prefix in the correct order and the builds LO. It would override the standard search pathes (mainly pkg-config tweaking). That script would take the same layer as the distro toolchain in the whole stack. 3. developer builds: + they need all features to make sure that they do not break anything; they do not mind about system libraries; IMHO, the more system libraries, the less potential build problems and the faster build = they will be happy if configure takes systems libraries if they are available by default I would prefer when it *only* takes a bundled library, if I explicitly force it to do so for some damn good reason. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
mu(*). You are asking the wrong question. The problem is that is suitable is not something that is easily decidable. Even less so by configure automagic. It often boils to making the choice between two sets of bugs (or a set of bugs vs. one big blocker). Well, this is a problem of exponential complexity. The only practically managable way to solve this (given the limited resources) is leaving this to the distros. They already have their infrastructures and resources to maintain thousands of packages in their various combinations. If a project like LO wants to handle this problem entirely on its own, this essentially means duplicating such distro infrastructures. So my clear vote is, dropping all bundled 3rdparty packages, import them via standard mechanisms (pkg-config, etc) and leave the rest to the distros. Now there are several cases to cope with: a) $distro lacks some packages (unlikely for the major distros) - step into the package maintainer role for those packages in that $distro and provide packages there. b) $distro doesnt keep up w/ LO upstream fast enough, so users might miss some features - step into the package maintainer role for LO in $distro and provide newer packages (most of it can be automatized) note: $distro might have good reasons for being slow at this point (eg. Ubuntu prefers stability over features). in this case, your newer LO packages might make it directly into the distro's official repository, but then we still can maintain our own vendor repository. c) certain people might want an fully self-contained packages, for environments that live completely out of any distro context (mostly: esoteric operating systems, like windows, that don't even know the fundamental concepts of package management and distros) - roll your own micro-distro - set up an build environment (eg. via chroot or sysroot'ed crosscompiler) that builds all required source packages (along the dependency graph) and bundles the output to one big binary package, that's going to be deployed in some different area (on unix-alike platforms that would be something like /opt/libreoffie/) In my professional carreer I already had several similar scenarios in various customer projects. Those who followed my advise, had a mid- and long-term hr saving in the scale 20..30% (after a few man-weeks initial efforts for the transition, of course), others who didn't follow me, still have contigiously increasing maintenance overhead. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Windows - MSVC vs. gcc
Hi folks, could anyone of the Windows experts please give me some insight, why you're using MSVC for LO, instead of gcc ? Is there anything important that cannot be done w/ gcc ? thanks. -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
(*) While this can (and did) happen just by changes in the package itself, automagically toggling configure-output is severly raising the risk. ACK. Build processes should be as predictable and deterministic as possible. Optimally, it should be a function (in mathematical terms) with as few parameters as possible. Things like automatic dependency switching - IOW: automatically switching on/off certain features or linking in certain libraries just by their precense in the building system - is quite dangerous as soon as that build result is put to another system. You neither can rely on a specific feature set (installing or removing one library in the building system may magically change the build output), nor can you know which libraries are actually required at runtime (without deeper analysis of the actual build output). Such behaviour is a nightmare for distro maintainers. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
Running ./autogen.sh --with-system-libs fails as soon as it finds one external library that does not exist system-wide (and there's pretty much bound to be one, given what all kinds of libs we use). build as an user which does not have additional (local) libraries installed ? So one has to try, fail, add one --without-system-foo, and repeat until it builds. And try again with next distro upgrade, or carry a growing list of options. Distro maintainers have to do the same, potentially for each release. So, why not just dropping all 3rdparty libs that are included in mainline distros ? Thinking of it, it'd be probably enough if --with-system-libs acted as --with-system-foo=auto for all such external libs. Such a build (binary image) will likely not be portable to other systems, as soon as the target system misses some of the libs that existed during build are not installed on the target system. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows - Embed Server et al.
It is also used in Groupwise for editing mail. Groupwise calls LO as editor ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ancient openssl bundled
As a sidenote, the need for openssl is not direct for LO, but something needed for dependencies. I wanted to remove openssl altogether and rely on nss instead, and you could almost hear the grunts of pain on irc. My feeling is that this dep is too obscure, so nobody wants to touch it... hmm, who exactly needs it ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows - Embed Server et al.
On Thu, 2012-04-19 at 16:34 +0200, Enrico Weigelt wrote: It is also used in Groupwise for editing mail. Groupwise calls LO as editor ? Or Microsoft Word - And this works on other platforms, ets say, GNU/Linux, *BSD, etc, etc ? hmm, does Groupwise client meanwhile fully work on GNU/Linux and *BSD ? (sorry, my contact with Groupwise is practically limited to migrating away to Zimbra ... ;-o) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows - Embed Server et al.
Hi Enrico, And this works on other platforms, ets say, GNU/Linux, *BSD, etc, etc ? I find it is often well worth engaging the brain before typing at the keyboard and creating noise for others to have to read. This was a serious question! I wouldn't be so much surprised if somebody (eg. from the wine or reactos area) already came up with a usable opensource OLE implementation, that might even be able to run win32 binary ole components. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: what can we learn from this add?
There are ways for Microsoft to promote the Office feature set without calling out alternatives, and there are more playful ways of drawing comparisons (thinking of the Mac v. PC business back-and-forth and the Windows Phone bake-off against your smartphone $100 bets). This just makes Microsoft folks look scared and heartless. ACK. When I clicked this link, I was really wondering if they had anything technologically interesting. But unfortunately this was just stupid FUD again. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
typesizes and memory usage on 64bit vs. 32bit
Hi folks, does anybody has some knowledge about LO's memory usage increase comparing 32 to 64 bit ? (heap data, not code). I've seen a massive memory consumption increase on Chromium since moved from 32bit to 64bit userland. Seems they quite frequently used plain int types which of course gets doubled in size then. I'm just curious if we've got the same problem in LO. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Development Äußere Bayreuther Str. 55, D - 90409 Nürnberg Tel: +49 911 72303-30 Fax: +49 911 72303-50 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
Not in the case of services rdbs. The information stored there is a mapping between (a) service and singleton names (as documented in UNOIDL), (b) the implementation names of entities implementing those singletons and services, and (c) the software artefacts that contain those implementations (dynamic libraries, jars, etc.). IMHO this information doesnt need to be stored in the registry at all. In the end, AFAIK, we somewhere have some factory (yet haven't found where that code actually is, so any help appreciated ;-o) which instantiates services by the given name. This factory could very well use some very simple datastructure, just a map. For the builin components that data could well be compiled-in (eg. via some code generater as shown by little script i posted yesterday). What I yet have to find out: where is there instantiation actually done ? I'd like to change that code in a way, that it first tries to do the lookup via the generated structures and then fallback to the registry. For types rdbs, on the other hand, the information is indeed currently duplicated (triplicated even, given the additional representation as Java class files). Improvement here is surely desirable. Can we directly load it from .idl files or generate a static data structure from them ? My tinkering with a radically simplified component context/service manager is going along quite well, btw. I hope I have enlightening numbers soon. Could you please give me some bit more insight, how that service manager actually works ? What's actually happening, from the point where somebody requests some service until where the requested service class is actually instantiated (the actual new() operations, in case of c++ ;-)) ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: string parameters
Before you dive deeper in the code, Lubos made a great job to simplify the use of RTL_CONSTASCII_USTRINGPARAM, you should read this : http://nabble.documentfoundation.org/RTL-CONSTASCII-U-STRINGPARAM-officially-obsolete-tp3881536p3881536.html Ah, I've already seen this mail, but just missed that part: functionFoo( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(X))) can be written as functionFoo( X ); So, the problem is already solved, right ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
On 04/04/2012 01:44 PM, Enrico Weigelt wrote: Can anybody please point me to the code which is loading the .rdb files ? stoc/source/simpleregistry/, but see my vague idea in another part of this tread for work that is currently under way in this area. thx, brought me some bits nearer to the point :) Now I'm curious how this data then is used for actual instantiation. My guess is that somebody calls the uno machinery for a service by given name, and then it looks into the registry, which component has an implementation of that service, correct ? By the way: what happens exactly when multiple implementations exist for some service name ? How is the decide made which one to take ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
snip / Just hacked up a little poc script wheich generates a static data structure from the *.rdb xml files. Of course, far away from usable, but should at least demonstrate the idea. cu parse_registry Description: application/php ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
Or, for files that are static in a distributed LO (i.e. not modified at installation. even less at run-time), process them into source code that set up the structures as much as possible at compile-time already? Even better! There seems to be a lot currently dynamic data, that could be directly compiled-in (landing .text or .cdata section) and so save a lot runtime overhead. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: string / size bits ... #2 ...
Just curious: what's the big difference between rtl::OUString and std::string ? http://lists.freedesktop.org/archives/libreoffice/2012-March/028485.html (and click the next message link a couple of times). Okay. Do situations where std::string doesnt suffice happen that often, that we need to OUString virtually everywhere ? I imagine lots of situations where even const char* is really enough. I doubt any compiler we use treats std::string specially, I'd expect it's a normal class for it just like any other. Honstly, I don't know. But I think it's certainly possible. That would be one of the first thing I tried when I wanted to write an good optimizing compiler. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
Hi, Yes, this is indeed a bit of a tragedy. The relevant UNO types and services bootstrapping code is very old, and concepts are tightly knit together there, and whenever you want to change something you risk backwards incompatibility. Backwards compatibility to whom ? Binaries ? Source ? User data ? At the heart of the matter there is the old binary store file structure and the XRegistry interface on top of it. At runtime, both all the UNO type information (scattered across a number of binary rdb files) and all the UNO service information (scattered across a number of rdb files that used to be binary but have been mostly changed to XML now) are represented by a single XRegistry instance each. What kind of data do these files hold ? Is that data somewhat changed after build or does it remain constant ? The way the respective information is represented in the XRegistry interface simply corresponds to the way the information is stored in the binary rdb files. How is that data structured ? How is it accessed, by whom ? It is ro or rw data ? Perhaps it could make sense to design a new interface and step by step get rid of the old one ? Hence, for example information about a UNO interface type com.sun.star.foo.XBar is stored in a nested folder with path com - sun - star - foo - XBar, containing little blobs of information about the type's ancestors, its methods, etc. Does that type name necessarily have to have path semantics, or would a flat string key also be fine ? As there are typically multiple rdb files containing types resp. services (URE specific, LO specific, from extensions, ...), but they need to be represented by a single XRegistry instance, so nested registries were invented. They effectively form a linear list of chaining XRegistry instances together. Whenever a path needs to be looked up in the top-level registry, it effectively searches through the linear list of nested registries. Does this nested XRegistry have mounting or union semantics ? Or both ? Can we compile that splitted registry into a big one ? When I introduced XML service rdbs, I sort of chickened out (see above for rationale) and put them behind an XRegistry facade, so that they would seamlessly integrate with the existing mess. I postponed systematic clean-up to the pie-in-the-sky days of LO 4 (or, once we'll become incompatible with OOo, as the phrase used to be back then). Which kind of incompatibility would happen exactly ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: extraordinary stoc/ thrash ...
What would be ultimately nice would be to rid ourselves of this XRegistry 'stuff' and have a simple XML file, read into some simple structures, and added to a couple of hashes for the common lookup patterns we want. Is there any chance of doing that separately, so we can sever the back-compatible .rdb reading for LibreOffice 4 mostly by code removal ? Maybe that XML file could even be mmap'ed, just having the index on heap. Depending on the actual structure and access patterns, the whole thing could also be splitted into several files, and just use the filesystem hierachy as index. Do you already have some ideas how that XML file would look like ? cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: string / size bits ... #2 ...
Hi, I don't want to spoil the fun much for you :) , but I expect the number of string allocations to go down when RTL_CONSTASCII_* stops being used in favor of string literals, and further down after whenever I get to implementing the efficient operator+. So you may be profiling a problem for a part of which a solution already exists. Just curious: what's the big difference between rtl::OUString and std::string ? I guess a good toolchain (compiler+stdlibs) can do a lot of optimizations, which it cannot with an own implementation. For example, if we have lots of static strings (literals, or statically initialized and const std::string objects), it could put them all together into one instance in const data section. I doubt that is possible with own classes without compiler support. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Providing a mysql connector extension on Linux that works independently of system mysql library versions - a pipe dream ?
The installation program stuff is needed though to install the program. Only on esoteric platforms that dont have a package management system. The right solution is clear: implement an package management there (maybe just port dpkg/apt) and then just us it. make install does that, and without that (and some steps it does) it becomes extremely hard if not impossible to create a install you can package from. I didnt mean the make rules, but such programs, that deploy the executables containing the application files and copy them into the running system. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
