Re: [Libreoffice] [PATCH] Old X11 code cleanup in libs-gui
On Fri, Jul 08, 2011 at 09:03:25PM +0200, Francois Tigeot wrote:
I'm a bit puzzled by code using what is almost a complete list of all
platforms running X11 to define some features:
We also have some code dedicated to finding the origin of different X11
implementations and working around their bugs (grep for GetServerVendor).
If nobody gives me a reason not to in the next days, I plan to remove both
the useless #if defined list and the whole XFree section.
Patch attached.
--
Francois Tigeot
From f416bb49a17909a5a540ea3050a24317dae1b6d6 Mon Sep 17 00:00:00 2001
From: Francois Tigeot ftig...@wolfpond.org
Date: Fri, 8 Jul 2011 23:01:55 +0200
Subject: [PATCH] Cleanup some old X11 code, remove useless tests
---
vcl/unx/generic/app/saldisp.cxx | 28
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/vcl/unx/generic/app/saldisp.cxx b/vcl/unx/generic/app/saldisp.cxx
index 36cd1c7..94a75c3 100644
--- a/vcl/unx/generic/app/saldisp.cxx
+++ b/vcl/unx/generic/app/saldisp.cxx
@@ -885,10 +885,7 @@ void SalDisplay::Init()
sscanf( pProperties, %li, nProperties_ );
else
{
-#if defined DBG_UTIL || defined SUN || defined LINUX || defined FREEBSD || \
-defined NETBSD || defined OPENBSD || defined DRAGONFLY
nProperties_ |= PROPERTY_FEATURE_Maximize;
-#endif
// Server Bugs Properties
if( GetServerVendor() == vendor_excursion )
{
@@ -909,31 +906,6 @@ void SalDisplay::Init()
if( otherwm == eWindowManager_ ) eWindowManager_ = mwm;
}
else
-if( GetServerVendor() == vendor_xfree )
-{
-nProperties_ |= PROPERTY_BUG_XCopyArea_GXxor;
-#if defined LINUX || defined FREEBSD || defined NETBSD || defined OPENBSD || \
-defined DRAGONFLY
-// otherwm and olwm are a kind of default, which are not detected
-// carefully. if we are running linux (i.e. not netbsd) on an xfree
-// display, fvwm is most probable the wm to choose, confusing with
mwm
-// doesn't harm. #57791# start maximized if possible
-if((otherwm == eWindowManager_)
-|| (olwm== eWindowManager_ ))
-{
-eWindowManager_ = fvwm; // ???
-nProperties_ |= PROPERTY_FEATURE_Maximize;
-}
-#else
-if( otherwm == eWindowManager_ ) eWindowManager_ = winmgr;
-#endif
-#if defined SOLARIS defined SPARC
-nProperties_ |= PROPERTY_BUG_Bitmap_Bit_Order;
-// solaris xlib seems to have problems with putting images
-// in correct bit order to xfree 8 bit displays
-#endif
-}
-else
if( GetServerVendor() == vendor_sun )
{
// nicht alle! (bekannt: nur Sparc II CG3, CG6?)
--
1.7.4.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Cherry-pick request: http://cgit.freedesktop.org/libreoffice/sdk/commit/?id=ff2c05d7b1411aeb67dc0ba415a1ec50db6331d6
Fixes one detail of our SDK. (It might still be broken in other ways.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Printer handling
Hi,
The printer handling code in
libs-gui/vcl/unx/generic/printer/printerinfomanager.cxx gets the list of
print queues with a combination of hardcoded platform names and shell
commands :
#if defined(LINUX) || defined(NETBSD) || defined(FREEBSD) || defined(OPENBSD)
{ /usr/sbin/lpc status, lpr -P \(PRINTER)\, , :, 0,
standardSysQueueTokenHandler },
{ lpc status, lpr -P \(PRINTER)\, , :, 0,
standardSysQueueTokenHandler },
{ LANG=C;LC_ALL=C;export LANG LC_ALL;lpstat -s, lp -d \(PRINTER)\,
system for , : , 1, standardSysQueueTokenHandler }
#else
{ LANG=C;LC_ALL=C;export LANG LC_ALL;lpget list, lp -d \(PRINTER)\, ,
:, 0, lpgetSysQueueTokenHandler },
{ LANG=C;LC_ALL=C;export LANG LC_ALL;lpstat -s, lp -d \(PRINTER)\,
system for , : , 1, standardSysQueueTokenHandler },
{ /usr/sbin/lpc status, lpr -P \(PRINTER)\, , :, 0,
standardSysQueueTokenHandler },
{ lpc status, lpr -P \(PRINTER)\, , :, 0,
standardSysQueueTokenHandler }
#endif
There are also some other things like this I don't like in this file:
/* TODO:
* porters: please append your platform to the Solaris
* case if your platform has SystemV printing per default.
*/
Trying to manage printers in one way or another depending on the operating
system name feels incredibly wrong for application code.
Shouldn't CUPS be the default printing system anywhere by now on Unix-like
systems ? Is there a reason to keep this sort of code as-is ?
--
Francois Tigeot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Libre Office
Hello Vanessa, On Sat, Jul 9, 2011 at 01:16, Vanessa Peay nessyness90...@gmail.com wrote: Hello, I installed libre office on my computer, but now it's taking up too much memory on my computer. I was trying to unistall it, and it wont let me uninstall it. How can I unistall it? This list is for developers, not for asking question. To ask, please send mail to us...@global.libreoffice.org instead. Please read http://wiki.documentfoundation.org/Development/Use_of_MailList and http://www.libreoffice.org/get-help/mailing-lists/ for more information. Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Old X11 code cleanup in libs-gui
Hi Francois, On Sat, 2011-07-09 at 08:20 +0200, Francois Tigeot wrote: If nobody gives me a reason not to in the next days, I plan to remove both the useless #if defined list and the whole XFree section. Patch attached. Seems like a lot of timely cruft removal :-) Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Urgent notice of Intellectual Property protection
In case you don't know, that was spam, just ignore it. Discuss it on the discuss list if you have to. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED-3-4] Libo 3.4.1: Cherry pick for fixing debug build
Thanks! On 07/06/2011 12:04 PM, Thorsten Behrens wrote: Thomas Arnhold wrote: it would be nice if this commit could be cherry-picked on libreoffice-3-4-1, because without it a debug build will fail at cui Cherry-picked to libreoffice-3-4. Don't think 3-4-1 makes too much sense, this is already released. Cheers, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Remove CREDITS.odt?
On 07/04/2011 09:14 PM, Thorsten Behrens wrote: Question is: Is Help-Libreoffice Credits menu entry necessary at all if there's a link to it within the about window? I don't think so. If we remove it, we could remove CREDITS.odt as well. Or at least we need to sync them. Hm, given the wide range of environments LibreOffice is deployed, I'd think a offline version has its charme - would you maybe want to sync with spaetz on updating the credits.odt every once in a while? Thanks for catching this, This is a good point. Is there any packaging script if a release rolls out? Maybe credits.odt update could be done automatically within this. Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Cherry-pick request: http://cgit.freedesktop.org/libreoffice/sdk/commit/?id=ff2c05d7b1411aeb67dc0ba415a1ec50db6331d6
On Sat, 2011-07-09 at 00:38 -0600, Tor Lillqvist wrote: Fixes one detail of our SDK. (It might still be broken in other ways.) Done, interesting that I was able to build third party extensions against the 3-4 sdk despite that already. I guess it wasn't used in that particular path. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Cherry-pick request for fdo#39091, gstreamer urls with accented chars not playing back
I suspect its merely the downshift to ASCII in avmedia http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=6b211c4735b3965429e82dc100ef0cd0db810fed is likely to fix it. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Doubled files: testsax.cxx?
Hi, I've found out, that there's a whole directory doubled in the tree: libs-gui/sax/test/sax and extensions/test/sax I think the first one is the desired and the second could be removed. Or is it intened, that libs-gui/sax/test/sax is an internal sax test and extensions/test/sax is the one using the uno interface (diff both testsax.cxx files). I need a little hint ;) Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Printer handling
On Sat, 2011-07-09 at 08:52 +0200, Francois Tigeot wrote: Shouldn't CUPS be the default printing system anywhere by now on Unix-like systems ? That seems reasonable to me. Cut down on the forest of potential configurations. I think there's some dlopen/dlsym hackery around for cups in there. Could make it an explicit dependency and strip that out too as part of that. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Doubled files: testsax.cxx?
On Sat, 2011-07-09 at 16:37 +0200, Thomas Arnhold wrote: Hi, I've found out, that there's a whole directory doubled in the tree: libs-gui/sax/test/sax and extensions/test/sax I think the first one is the desired and the second could be removed. Well, extensions and sax are both old-school build module so prj/build.lst shows what gets built, test isn't listed in either of them, so neither are built. Doesn't look like either have gotten much love since 2002. I doubt the one in extensions can be easily made to build, lots of L strings which suggests it only built under windows back in the day. The one in sax looks recoverable. So yeah, could remove the second one in extensions anyway. Additionally it would be good if the first one in sax could be made to build anyway as a first step. e.g. bung it into prj/build.lst and/or run dmake manually in that dir and fix it up to build. With the ideal situation being that it could be folded into the qa/cppunit tests in sax if it does something useful C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC] [helpfiles] Report
Dear everbody, Andras gave me a helpful feedback about my program. Because of that I discovered some issues and added them to my list. There are several things which need to be done. (see below) So far I fixed some bugs in my convert.py. Also I implemented the feature to set a custom start page. The execution of wine works better now because it restores the user´s settings after it´s done. This is my todo-list: Set correct article titles - getArtNames shall add the translated titles to its output - Replacement of titles in docbook.xml Create a docbook for each language - getArtNames shall create a list ordered by language Change the layout of output to title + hr + content. - Set another stylesheet for xslt Make wine optional. On windows prefer direct execution of HHC. Avoid creation of links to external foreign sites Include images in page titles Implement index creation - Maybe switch to a framework that does that for me - Might be important for the feature that the help file opens correctly and at the correct place on each platform. Improve the usage of convert.py - Accept command line parameters Cheers, Timo ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Urgent notice of Intellectual Property protection
I received one of these. I did a little nosing around an found what they were talking about with regard to one of my domain names. I don't know if it is a real threat to squat on a related domain name or it is a way to extract protection money. In my case, I told them I was not concerned about other registrations and if they required some sort of official quite claim from me I would be glad to supply it. I received an acknowledgment and no further contact ever. I have never received one of these for a domain name that was not associated with a business or organization. Only my business domain. - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of Tor Lillqvist Sent: Saturday, July 09, 2011 01:44 To: libreoffice@lists.freedesktop.org Subject: Re: [Libreoffice] Urgent notice of Intellectual Property protection In case you don't know, that was spam, just ignore it. Discuss it on the discuss list if you have to. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Are we back to having this spec process again!?
Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? Not to mention I'm very disturbed by this. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] comments translation
Hi Cedric, following you find the comments I've promised... Line numbers refer to lines in your patch. line 90: Statics fuer Umrandungsalignment setzen. Set borders alignment statics. line 203: Ausrichtung - orientation line 246: Irrtum - mistake (error sounds to me like the error you have when fitting a model to data, mistake is more that something is wrong - but I'm not a native speaker, so it might be a matter of taste...) line 267: Is is - Is it line 386: the German version expresses that the array might shrink (in the future) and not that it might have shrunk (in the past). Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Are we back to having this spec process again!?
Hi Kohei, you know that I'm both subscribed to this bug, so I feel free to comment on this - rather from the UX point-of-view (although I know some people from Documentation, QA, ... who think similar). Am Samstag, den 09.07.2011, 13:39 -0400 schrieb Kohei Yoshida: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I'd like to say that he offered to write a specification - which is a bit different from a full-fledged process. Isn't it positive if somebody (whoever this is) cares about collecting the information if the complexity of the issue avoids handling all inside a simple bug report? Especially if nobody urged him to do so - he already invests a lot of time for LibO. As Rainer stated, some of the changes do affect some rather fundamental definitions within the help - how should the Documentation team know? And the different example documents showed (at least for me) that separating the issue from the intended behavior is difficult. If we change that behavior - how should QA know what to test? I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? I welcome if people announce / describe some of the intended changes without major changes in the visible functionality. But, I currently perceive a lot of doubled work outside the development team due to the lack of information. There are also some examples within Calc where such a lack of information requires a lot more time for UX and Usability work (although we lack developers, currently it is Development Power UX). However, bothering the developers for details about the intention, the detailed behavior or having fundamental discussions in the issue tracker after a change has been introduced - I think that's tedious for developers as well. We should avoid that. Not to mention I'm very disturbed by this. I'm sorry that you feel like this - I'm sure this wasn't intended by Rainer. But I have to admit that some people (myself included) / teams feel irritated by lacking information (in advance). Maybe this is a good starting point to re-think how non-trivial changes are worked on ... switching from Easy to Serious Hacks :-) Any interest? (Also on another list, in a conf call, or ...) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Are we back to having this spec process again!?
Christoph, I feel that you are taking this in a bit too generalized way. I'm talking about the use of a specification for this particular bug report, which I repeatedly said is overkill. Anyway, my answers are below. On Sat, Jul 9, 2011 at 4:46 PM, Christoph Noack christ...@dogmatux.com wrote: Hi Kohei, you know that I'm both subscribed to this bug, so I feel free to comment on this - rather from the UX point-of-view (although I know some people from Documentation, QA, ... who think similar). Am Samstag, den 09.07.2011, 13:39 -0400 schrieb Kohei Yoshida: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I'd like to say that he offered to write a specification - which is a bit different from a full-fledged process. Isn't it positive if somebody (whoever this is) cares about collecting the information if the complexity of the issue avoids handling all inside a simple bug report? So, here are few things I need to mention. I don't consider this particular bug report to be anywhere near complex. It's a simple bug report where the reporter was expecting to print a sheet with only cell colors on it, but Calc wouldn't print it because Calc consider that sheet to be empty. That's all. But somehow, during the triage, an additional bug was discovered in Calc's auto print range detection, which confused me initially but in the end I sorted it out and summarized it in two bullet points in Comment 11, which I quote here --- So, this is a combination of two separate issues. 1) Sheets with only cell colors are not printed unless the printing of empty sheets is enabled, either in the Calc Print option page or in the printing dialog. 2) Even with the printing of empty sheets is enabled, Calc's automatic range detection fails to detect correct printing ranges. --- And I believe both Rainer and Regina were focusing on point 2), which is different from the original bug description, which was point 1). I was later going to split 2) into another bug report, but anyways... So, the decision we needed to make, as far as the original bug report was concerned, was whether it would make sense to treat a sheet with only cell colors as a non-empty sheet. That's all, at least in my mind. Then, Rainer offered this specification http://wiki.documentfoundation.org/Calc_-_Printing_of_Cells_without_Contents which contains A LOT more information than my bullet point 1). I don't know about you, but I want to keep simple things simple, and I want to keep the amount of information proportional to the level of complexity (or simplicity) of the issue being handled. So, I was a bit surprised to see that much description borne out of this simple bug report. Especially if nobody urged him to do so - he already invests a lot of time for LibO. Sure. But if someone writes a specification someone else has to read it to verify it. So, to me, writing a very detailed description for such a simple bug report is anti-productive, for everybody involved (and I happen to be listed as the developer). As Rainer stated, some of the changes do affect some rather fundamental definitions within the help - how should the Documentation team know? By asking us, or checking the release notes, where we gather all significant changes between releases. And the different example documents showed (at least for me) that separating the issue from the intended behavior is difficult. If we change that behavior - how should QA know what to test? By asking us, or checking the release notes, or maybe something else we need to come up with for QA. Note that we do also care about improving the QA-ability of new features, so please don't think for a second that we don't care about this. But I do feel strongly that specification is not the answer to this. That's like trying to kill a mosquito with a bazooka. I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? I welcome if people announce / describe some of the intended changes without major changes in the visible functionality. But, I currently perceive a lot of doubled work outside the development team due to the lack of information. Sure, and that's surely an area we want to see improved. But the first step to that will be improving our communication on how to solve this. Again, I don't think writing specification is an answer there either. There are also some examples within Calc where such a lack of information requires a lot more time for UX and Usability work (although we lack developers, currently it is Development Power UX). However, bothering the developers for details about the intention, the detailed behavior or having fundamental discussions in the issue tracker after a change has been introduced - I think that's tedious for developers as well. We should avoid
