Re: [Libreoffice] LO status bar annoyances
On Tue, 30 Nov 2010 16:22:36 +0100, Regina Henschel wrote: > Sebastian Spaeth schrieb: > > Am I the only one finding the current status bar pretty much useless? > Yes ;) OK, let me be more precise "has improvement potential in its current form" :) > To learn more about the status bar have a look at > http://www.ooowiki.de/StatusLeiste. It is in German and needs an update, > but the text shows, that the status bar is a great tool. This is a great document BUT (:-))... the need to write as the first sentence on each item whether it requires a single or a double-click already shows that the status bar items can be improved. The help text on that page is great, eg. BLK is described really nicely. My English within-LO help page say on BLK: "A block of text can be selected." ahh, mmh, ohh,...right. WUT? And the item has no tooltip at all by default. If you need to point me to a 3rd party wiki page in German to explain me how selection modes work mean that *we* (as in LO) didn't do a good job. (which I exaggerate to 'useless') > To get all the nice extended tips, I have added the button "Extended > Tips" (German "Aktive Hilfe") (category "Application") to the symbol > bar, so that I can switch it easily on and off. Ahh, that is a nice one. Unfortunately, I cannot assign an icon to it, so it is displayed as a very wide text. Thanks. Sebastian pgpX6jeuDSOiR.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 30 Nov 2010 19:50:28 +0100, Cor Nouws wrote: > Information given by the status bar, plus the control options it gives, > often is important for users I advise. Nobody, lest I, doubts or denies that. But do your users like to remember on which items they have to single, or double-click to launch actions too? :-P I am nor proposing to do away with it, I am proposing to improve it. Sebastian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 30 Nov 2010 09:54:37 -0500, Kohei Yoshida wrote: > > a) This is the standard state of my documents (see, I tend to modify > > docs in a editor, DOH), and that exclamation mark purports some > > sense of urgency and failure. > Sorry I have to disagree there. Thanks for the info Kohei. To avoid duplication, see the mail I just sent as a reply to Christoph Noack's mail. The management summary: * My favorite solution would be to have a) the save button always work but b) have the save button convey the information whether it thinks that it is currently useful or not (grayed out, or overlaid asterisk,...) * More realistically, I don't have anything against a status bar icon if done right, ie: - no tooltips over empty space, and empty separators, and no danger-implying fat exclamation marks. Christoph proposed nice items, that would make me totally happy. Sebastian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Part 2 on the Changed icon part. On Tue, 30 Nov 2010 22:31:44 +0100, Christoph Noack wrote: > DOCUMENT CHANGED INDICATION> > A solution should: > * just work > * be unobtrusive (don't catch attention if it isn't required, > don't waste space) > * be self-explanatory (if possible) Right Ideally, we would not need that status bar and change the "Save" icon depending on whether there are changes that can be saved or not (e.g. overlay it with a yellow asterisk or so). I am one of the persons that agree that the save button should always work. But that doesn't mean that the save button cannot convey information on whether it is currently sensible to do so. (Alternatively gray it out if unmodified, but still allow it to be pressed). This would be my favorite solution. Putting that aside, let's work on making the status bar icon non-annoying, our ideas are pretty much the same. > But the current solution isn't perfect, of course. Current issues: > * The extended help tip still mentions the '*' for a changed > document. Right, tiny issue > * For unsaved documents, the normal tool tip mentions "The > document has not been modified since the last save." (Small > issue, may not be changed). I don't have a problem with that, except that I have to mouse over an apparently empty are to see that toolbar. Why not always have an icon that changes appearance? > * The red "!" is indeed a bit strange considering the importance > of this message. And is the main reason of my hate for the icon :). One example of how users sometimes get hung up at very tiny unimportant details. ;) > * The icon does not communicate any behavioral difference - it is > just a status information, but looks very similar to the view > mode buttons etc. I don't have a problem with that. > * The "double-click behavior" is inconsistent to all platforms I > know of. It may even be problematic for some users ... > personally, I would remove it. You are not saying I can launch an action on that one, can you? /me tries. Uhh, never thought of that. Interesting, but pretty much superfluous. Unfortunately, the discussion has pretty much gone in a direction that suggests I want to do away with a "changed indication" completely, which is not the case. My 2 main objections are: - the horrid exlamation mark icon (I see exclamation marks in my OS only in case of errors or other severe warnings, not for something I consider the default situation. - if unmodified, we reserve the space showing an empty area with group box separators. Your concluding advice is pretty much congruent with what would do away with my annoyance of the issue. See below: > But how to address the issues you raised? My personal take: > * Keep the status indicator where it is (in the status bar) Fine with me > * If the document is unmodified, add some very subtle document > shape. Then, there is a reason for showing a tool tip and the > "What's that?!" effect may be reduced. Which would be great. Now, if we could remove the separator to the right (which are more icons), that would even be greater, but require more coding assume. > * For the modified document, reduce the "warning" level and - > maybe - just show a document icon with a yellow star in it. This > a) is similar to the old '*', and b) is used for to indicate new > documents on certain platforms. Perfect. I had thought about a faint empty doc, versus a fat-bordered doc with text in it, but you suggestion is much better, easier to recognize and more in line with what other editors do. > And, just a small intentional idea - what about adding a bit more value > to this "feature". For example, add the "Document is modified. Saved XXX > minutes ago." time to the tool tip. If things go wrong, people tend to > look at their data files to know how long they have been working on this > document - so discarding any changes might then be safe. Would be a nice additional touch if we have that information. > Well, I hope this helped anyhow ... I don't know :-) It sure did. Sebastian pgpC8XkTPaC27.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
On Tue, 30 Nov 2010 22:31:44 +0100, Christoph Noack wrote:
Thanks, I am going to reply to this in 2 parts. One on the general
status bar part and one on the changed icon issue to keep them separated
and the mails readable.
> STATUS BAR
> For example, the little '*' is mainly caused by the need for a very compact
> symbol - here, please think in 480px width.
Is there still a little *? I've never seen one in current LOs...
> Some more issues of the current design:
> * The indicators mix information and invisible actions (click,
> double-click for some surprise)
> * Information is shown by hiding it (document changed status,
> document signed status)
> * It misses charm with all its "INSRT", "BLK" and "STD" (And, when
> the block selection has been introduced, the menu has been
> changed to introduce a bit more clutter, sigh.)
> * It looks very dated and cluttered
That is a nice summary. If you add to it:
* Actions are launched by clicking on empty areas (related to hiding
information)
* Not only missing charm, but also missing helpful tooltips. And an
easy link to the help page. And the help page's text is awful :).
* It provides access to some IMHO rarely used functionalities where I
would love to see other things in that space. Has the
UI project collected data on how often people *intentionally* :-)
changed from INSERT to OVERWRITE mode?
> Concerning the "dated look": The OOo guys reworked the status bar to
> remove some of the lines and boxes. Here is some discussion [1], and the
> issue [2].
As for [2], the removing of "group boxes", I would agree to remove the
apparently automatic and unavoidable insertation of them. I do think it
makes sense to be able to specify "separators" manually in the .xml file
where it makes sense, just as we do with menus nowadays.
> Concerning the weird information representation: Within the discussions
> of the "new" zoom slider, I started to add ideas how to rework the
> status bar. Today, I would have done it a bit different, but maybe it's
> interesting for you to look at antique (3 years old) data :-) [3]
Thanks for the shot, the zoom slider is actually the one thing I use
more often and which I am quite happy with. Naively, I would say you
don't need + and - buttons if you have the slider available. I could
also do away with the percentage number as long as I have the mark at
the 100% zoom level as a visual aid.
> You may notice, that the selection modes thing has been changed, and
> that all the items in the status bar got their own visual symbol to
> improve the representation. I also added "no outline level" ("Keine
> Gliederungsebene") to teach the user what the slot is used for (today,
> it is empty). This might have helped to reduce the hazzles one could
> read today on the TDF discuss list [4].
I kind of like the selection icons, what I do *not* like is that a) now
4 buttons occupy space for a rarely used function and b) there is no
visual aid as to what these do (the icons look a bit like they could
perform some alignment at first glance), so I'd propose to put the
currently selected icon in *one* button, which pops up all 4 modes in a
vertical row with a "Selection Mode" header (and a link to the help
entry) above it all.
> but we should be careful to remove something which had been
> intentionally added by Microsoft some years ago.
If we talk about being inspired by Microsoft, I would love to ditch some
items for a permanent word count as I've seen in MS Office 2010. Much
more useful status information.
To sum up my mail item: To do away with lots of my frustration we would:
- Not have inconsistent click-double click behavor
- Lose *some* of the separators/group boxes and don't reserve the space
when the status icon is not shown.
- Don't launch actions clicking on apparently empty space, or show
tooltips there.
- Either do away, or give some more clue as to what Selection Mode is.
- Change the icon of the "changed indicator" (but I will elaborate on
that).
Sebastian
pgpPudYTCtmMc.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Accelerate perl installer: optimize installer::scriptitems::optimize_list().
Another performance improvement for the perl installer. This one
brought my ./bin/ooinstall -l time down from about 4 1/2
minutes to under 4 minutes. (Warning: that number is in the right
ballpark, but is from a very small number of install runs.) The only
functional change was to trim all leading/trailing whitespace from the
list elements before eliminating duplicates (the old function only
checks half of the leading/trailing edges, and which edge depends on
where in the list the element came from; I couldn't find a good reason
for that pattern, so I made it uniform).
I'm finding the NYTProf module useful for finding performance
bottlenecks in the perl code, although on my system the times seem to
bloat out by a factor of 3 or so with the profiler running.
LGPLv3+/MPL.
Jordan Ayers
From 7d6e4413d90f9e7bc6451b89fe3c481a303279de Mon Sep 17 00:00:00 2001
From: Jordan Ayers
Date: Tue, 30 Nov 2010 22:36:28 -0600
Subject: [PATCH] Accelerate perl installer: optimize installer::scriptitems::optimize_list().
Replace call to convert_stringlist_into_hash with a simpler method using split; this requires significantly fewer data copy operations.
The new routine strips all whitespace from the front and end of each value; the old function call stripped leading whitespace, most of the time.
---
solenv/bin/modules/installer/scriptitems.pm | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/solenv/bin/modules/installer/scriptitems.pm b/solenv/bin/modules/installer/scriptitems.pm
index b96b77b..6ba76fe 100644
--- a/solenv/bin/modules/installer/scriptitems.pm
+++ b/solenv/bin/modules/installer/scriptitems.pm
@@ -2031,11 +2031,16 @@ sub quoting_illegal_filenames
sub optimize_list
{
my ( $longlist ) = @_;
-
+my %tmpHash;
my $shortlist = "";
-my $hashref = installer::converter::convert_stringlist_into_hash(\$longlist, ",");
-foreach my $key (sort keys %{$hashref} ) { $shortlist = "$shortlist,$key"; }
-$shortlist =~ s/^\s*\,//;
+
+$longlist =~ s/^\s*|\s*$//g;
+$longlist =~ s/\s*,\s*/,/g;
+
+foreach ( split /,/, $longlist ) { $tmpHash{$_} = 1; }
+
+foreach (sort keys %tmpHash ) { $shortlist .= "$_,"; }
+chop( $shortlist );
return $shortlist;
}
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Important: for your next pull do ./bin/g pull -r BEFORE git pull -r
Pushed, thanks Norbert On Tue, Nov 30, 2010 at 10:20 PM, Takeshi Abe wrote: > Hi, > > On Tue, 30 Nov 2010 21:02:05 -0600, Norbert Thiebaud > wrote: >> Important: for your next pull do ./bin/g pull -r BEFORE git pull -r > Could you apply the attached patch for /bin/sh? > > Cheers, > -- Takeshi Abe > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Important: for your next pull do ./bin/g pull -r BEFORE git pull -r
Hi,
On Tue, 30 Nov 2010 21:02:05 -0600, Norbert Thiebaud
wrote:
> Important: for your next pull do ./bin/g pull -r BEFORE git pull -r
Could you apply the attached patch for /bin/sh?
Cheers,
-- Takeshi Abe
>From 5940e81d9c9fd7b48b292a66781f3f9ee214ce9b Mon Sep 17 00:00:00 2001
From: Takeshi Abe
Date: Wed, 1 Dec 2010 13:08:49 +0900
Subject: [PATCH] ban bashism
---
autogen.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index 27ea62a..6509b40 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -9,7 +9,7 @@ if test "z$1" = "z--clean"; then
exit 1;
fi
-function requote
+requote()
{
local q=\'
set -- "${@//\'/$q\'$q}"# quote inner instances of '
--
1.7.2.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Yifan changed: What|Removed |Added Depends on||32010 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 --- Comment #19 from Yifan 2010-11-30 19:21:40 PST --- Nominate bug 32010 - LibO crashes when clicking a Table control body with control design mode off. Though I am not sure how many users will use this function, in my side, this can only be revealed by an exceptional automation testing log. This risky scenario happens when a user opens a document contains a 'Table control'. By default, LibreOffice opens a document with Design mode Off. So whenever the user click a control table body, Libreoffice will crash always. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Important: for your next pull do ./bin/g pull -r BEFORE git pull -r
Important: for your next pull do ./bin/g pull -r BEFORE git pull -r ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 --- Comment #18 from Kohei Yoshida 2010-11-30 18:30:21 PST --- I just filed Bug 32007 - EvolutionLocal database has no table to display. Do you guys think that this should be a blocker? It's not life-threatening, but a bit weird and embarrassing. Also, the fix may be potentially very simple. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Attention: The changes to the build system are about to be pushed....
in the next few minutes ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Fedora-specific hyperlink bug?
On 11/30/2010 04:09 PM, Caolán McNamara wrote: On Tue, 2010-11-30 at 10:36 -0500, Joe Smith wrote: Can someone running LibO on Fedora try and reproduce this bug: document hyperlink with utf-8 characters fails export to PDF http://qa.openoffice.org/issues/show_bug.cgi?id=115788 So far no one else can reproduce it. I can. Its a problem in vcl/source/gdi/pdfwriter_impl.cxx and DECODE_WITH_CHARSET. We now always write as US_ASCII to pdf now, which is one change from 3.2.1, so pretty much anything with DECODE_WITH_CHARSET in that file is very dubious unfortunately. The attached two alternative fixes would fix it for me. Either don't decode URIs and leave %XX in them (This might adversely affect the "Launch" target, whatever that exactly does in PDF), or assume that we can write as UTF-8 always. Probably need to go read the pdf spec to see what's the correct option here. C. Thanks for having a look. Someone else confirmed it privately. From your comments, it seems like this would affect all platforms. I wonder why some people don't see it? Is there something else I can do here to follow up? A report on fdo? http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Remove duplicate 'placeholder' icons
Hi everybody,
On 11/26/2010 08:42 PM, Michael Meeks wrote:
Where ImageList::GetImage is called
from, I don't know, we should audit that too...
...
$ grep _ZNK9ImageList8GetImageERKN3rtl8OUStringE */unxlngi6.pro/slo/*
Binary file framework/unxlngi6.pro/slo/imagemanagerimpl.o matches
Binary file sfx2/unxlngi6.pro/slo/imgmgr.o matches
Binary file sfx2/unxlngi6.pro/slo/module.o matches
Binary file sfx2/unxlngi6.pro/slo/styfitem.o matches
Binary file sfx2/unxlngi6.pro/slo/templdlg.o matches
Binary file vcl/unxlngi6.pro/slo/image.o matches
And we have five real hits :-) of course, we need to find the relevant
modules that produced those object files - but hopefully it narrows it
down a bit ?
Nice trick! It reminds me things I used to perform a few years ago. 5
years programming in Java makes a man lazy...
Ok, on my side I have more hits, don't know why.
$ grep _ZNK9ImageList8GetImageERKN3rtl8OUStringE */unxlngx6.pro/slo/* |
wc -l
-> 95 matches...
I concentrated in this one:
framework/unxlngi6.pro/slo/imagemanagerimpl.o as it looks used by some
central configuration code:
From the opengrok site, ImageManagerImpl is used in
- ImageManager, used in UIConfigurationManager.
- ModuleImageManager, used in UIModuleConfigurationManager.
This piece of code is called to load icons related to toolbars.
The patch attached allows to fallback on a default icon for a toolbar item.
Here is the test I have done:
Add the 'About Libre Office' entry to the standard toolbar, using an
existing icon.
in ~/.libreoffice/.../lc_imagelist.xml there is the following entry:
I replace .uno:About by .uno:AboutFoo, I restart soffice and the default
icon is now loaded for the About button :-)
So basic scenario looks ok. Some other tests I should do?
Regards,
Joachim.
diff --git a/sd/source/ui/view/viewoverlaymanager.cxx b/sd/source/ui/view/viewoverlaymanager.cxx
index 1a09d86..d2fa1fe 100644
--- a/sd/source/ui/view/viewoverlaymanager.cxx
+++ b/sd/source/ui/view/viewoverlaymanager.cxx
@@ -45,7 +45,6 @@
#include
#include
-#include
#include
#include
diff --git a/framework/source/uiconfiguration/imagemanagerimpl.cxx b/framework/source/uiconfiguration/imagemanagerimpl.cxx
index fabf676..5cfa9d1 100644
--- a/framework/source/uiconfiguration/imagemanagerimpl.cxx
+++ b/framework/source/uiconfiguration/imagemanagerimpl.cxx
@@ -63,6 +63,8 @@
#include
#include "svtools/miscopt.hxx"
+#include "vcl/imagerepository.hxx"
+
//_
// namespaces
//_
@@ -322,7 +324,6 @@ Image CmdImageList::getImageFromCommandURL( sal_Int16 nImageType, const rtl::OUS
ImageList* pImageList = impl_getImageList( nImageType );
return pImageList->GetImage( pIter->second );
}
-
return Image();
}
@@ -361,7 +362,17 @@ GlobalImageList::~GlobalImageList()
Image GlobalImageList::getImageFromCommandURL( sal_Int16 nImageType, const rtl::OUString& rCommandURL )
{
osl::MutexGuard guard( getGlobalImageListMutex() );
-return CmdImageList::getImageFromCommandURL( nImageType, rCommandURL );
+Image aImage = CmdImageList::getImageFromCommandURL( nImageType, rCommandURL );
+
+if (!aImage)
+{
+BitmapEx rBitmap;
+bool res = ::vcl::ImageRepository::loadDefaultImage(rBitmap);
+if (res) {
+aImage = Image(rBitmap);
+}
+}
+return aImage;
}
bool GlobalImageList::hasImage( sal_Int16 nImageType, const rtl::OUString& rCommandURL )
@@ -953,8 +964,9 @@ throw ( ::com::sun::star::lang::IllegalArgumentException, ::com::sun::star::uno:
if ( !aImage && m_bUseGlobal )
{
aImage = pDefaultImageList->getImageFromCommandURL( nIndex, aStrArray[n] );
-if ( !aImage )
+if ( !aImage ) {
aImage = rGlobalImageList->getImageFromCommandURL( nIndex, aStrArray[n] );
+}
}
aGraphSeq[n] = aImage.GetXGraphic();
diff --git a/toolkit/source/layout/core/helper.cxx b/toolkit/source/layout/core/helper.cxx
index 0afd3a4..791901b 100644
--- a/toolkit/source/layout/core/helper.cxx
+++ b/toolkit/source/layout/core/helper.cxx
@@ -595,7 +595,7 @@ uno::Reference< graphic::XGraphic > loadGraphic( const char *pName )
if ( aStr.compareToAscii( ".uno:" ) == 0 )
aStr = aStr.copy( 5 ).toAsciiLowerCase();
-if ( !vcl::ImageRepository::loadImage( OUString::createFromAscii( pName ), aBmp, true ) )
+if ( !vcl::ImageRepository::loadImage( OUString::createFromAscii( pName ), aBmp, true, true ) )
return uno::Reference< graphic::XGraphic >();
return Graphic( aBmp ).GetXGraphic();
diff --git a/vcl/inc/vcl/imagerepository.hxx b/vcl/inc/vcl/imagerepository.hxx
index a9009df..cb1dc2a 100644
--- a/vcl/inc/vcl/imagereposito
Re: [Libreoffice] [UX] LO status bar annoyances
Hi Christoph, all, Christoph Noack wrote (30-11-10 22:31) Some more issues of the current design: [...] Agreed? I do not object improving the Status Bar. Although I tend to find other subjects more important. But that is just me of course, who fights more with compatibility issues then with lacking/superfluous info on a bar at the bottom of the window. Speaking about info: there is an OOo issue to add the column position in the text (and the height ? can't remember that) to the status bar. People know that from Word. And now that we say wordprocessor: we have a status bar to in Calc, Impress, Draw, ... Pls keep in mind if possible improvements are valid for those too. Well, I hope this helped anyhow ... I don't know :-) Who would dare to deny that? I surely not ;-) Ciao - Cor -- - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Hi Thorsten, hi Sebastian, all! :-)
Am Dienstag, den 30.11.2010, 12:00 +0100 schrieb Thorsten Behrens:
> Sebastian Spaeth wrote:
> > Am I the only one finding the current status bar pretty much useless?
> >
> Nope. I hear you, pretty much unconditionally. Adding UX tag &
> Cc-ing my favourite UX homie. :)
I hope you know to whom you sent your mail ;-) But, mmh, since we
finally want to come in touch with some more UX guys, how about adding
the Design mailing list for such issues?
Although I'd like to refer to some of the issues already discussed here,
I feel free to start a new thread - to keep some thoughts in one place.
But what to think about? Well, it seems the discussion is about: the
"document changed" indication, and the status bar in general.
STATUS BAR
Let's start with the latter ... Sebastian named the thread "LibreOffice
status bar annoyances" and he is somehow right. There are issues
resulting from a very old and a "driven by constraints" design. For
example, the little '*' is mainly caused by the need for a very compact
symbol - here, please think in 480px width.
Some more issues of the current design:
* The indicators mix information and invisible actions (click,
double-click for some surprise)
* Information is shown by hiding it (document changed status,
document signed status)
* It misses charm with all its "INSRT", "BLK" and "STD" (And, when
the block selection has been introduced, the menu has been
changed to introduce a bit more clutter, sigh.)
* It looks very dated and cluttered
Agreed?
Concerning the "dated look": The OOo guys reworked the status bar to
remove some of the lines and boxes. Here is some discussion [1], and the
issue [2].
Concerning the weird information representation: Within the discussions
of the "new" zoom slider, I started to add ideas how to rework the
status bar. Today, I would have done it a bit different, but maybe it's
interesting for you to look at antique (3 years old) data :-) [3]
You may notice, that the selection modes thing has been changed, and
that all the items in the status bar got their own visual symbol to
improve the representation. I also added "no outline level" ("Keine
Gliederungsebene") to teach the user what the slot is used for (today,
it is empty). This might have helped to reduce the hazzles one could
read today on the TDF discuss list [4].
Concerning the "view selectors" at the bottom: Some of you might not use
it, but we should be careful to remove something which had been
intentionally added by Microsoft some years ago. I'm sure they did some
serious research ... especially when looking on our totally screwed UI
that hides these options in the "Zoom ..." dialog (a side note: we do
have a view menu).
DOCUMENT CHANGED INDICATION
I read all the comments very carefully and I understand some thoughts
and concerns. However, the constraints / requirements do support Kohei's
solution (if we want to keep the current save toolbar icon approach).
A solution should:
* just work
* be unobtrusive (don't catch attention if it isn't required,
don't waste space)
* be self-explanatory (if possible)
Concerning the latter, this is impossible with any approach. But to
inform the user, the title bar totally misses any kind of tool tip or
help text that explains its use(fulness).
But the current solution isn't perfect, of course. Current issues:
* The extended help tip still mentions the '*' for a changed
document.
* For unsaved documents, the normal tool tip mentions "The
document has not been modified since the last save." (Small
issue, may not be changed).
* The red "!" is indeed a bit strange considering the importance
of this message.
* The icon does not communicate any behavioral difference - it is
just a status information, but looks very similar to the view
mode buttons etc.
* The "double-click behavior" is inconsistent to all platforms I
know of. It may even be problematic for some users ...
personally, I would remove it.
But how to address the issues you raised? My personal take:
* Keep the status indicator where it is (in the status bar)
* If the document is unmodified, add some very subtle document
shape. Then, there is a reason for showing a tool tip and the
"What's that?!" effect may be reduced.
* For the modified document, reduce the "warning" level and -
maybe - just show a document icon with a yellow star in it. This
a) is similar to the old '*', and b) is used for to indicate new
documents on certain platforms.
And, just a small intentional idea - what about adding a bit more value
to this "feature". For example, add the "Document is modified. Saved XXX
minutes ago." time to the tool tip. If things go wrong, people tend to
look at their data files to know how long they have been working on this
Re: [Libreoffice] Script to find undocumented classes
Lubos Lunak wrote: > On Tuesday 30 of November 2010, Thorsten Behrens wrote: > > Additionally, I think most classes don't necessarily need detailed > > docs for all methods in the first place (which may also hurt later > > merging from OOo), but would already benefit from a two-line > > "mission statement" at class level (of course plus some module-level > > overview of "what's inside"). > > I beg to differ. After having years of experience using a nice, intuitive > and > well-documented APIs (Qt,KDE), and being used to that, I sometimes rather > suffer getting familiar with this codebase. Most APIs are not documented at > all (or at most poorly, or in German, which is about the same in practice for > many people). This is futher made worse by some APIs not being very intuitive > (cryptic abbreviations, unclear naming, obsolete idiosyncracies, duplication, > basic things being needlessly complicated). > Hi Lubos, adding documentation for what you describe doesn't help much, if at all. Core API is reasonably documented, see offapi/udkapi/sal/basegfx. The most egregious cases of hard-to-grasp methods surely live in the applications cores, use lots of weird abbreviations - and to document their behaviour succinctly would prolly require as much prose as there's code already inside them (i.e. multiple pages). For me, a cleanly designed class with one and only one task (and a proper mission statement, maybe - superfluous even for something like "String"), does not need much method documentation. Suitably-chosen method names, especially if they don't take 10 parameters, and only work for exactly 42 combinations of them, are almost self-documenting. I simply refuse the notion that adding superficial documentation to crappy api gets us anywhere - which does not rule out storing hard-won knowledge of class purpose, inner workings, important pre- or postconditions at times - and if it makes sense, as method- or class-level doxygen documentation. But to really fix the problem you mention, I'm afraid only large-scale refactoring helps. And wrong documentation surely is worse than no documentation. (sorry for the rant, that struck a chord. Also, I'm clearly with you that larger parts of vcl & [sv]tools public headers are in dire need of method-level documentation. I'd even suggest to start there, that code does not change much) Cheers, -- Thorsten pgpxbxY0c6BKk.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Fedora-specific hyperlink bug?
On Tue, 2010-11-30 at 10:36 -0500, Joe Smith wrote:
> Can someone running LibO on Fedora try and reproduce this bug:
>
> document hyperlink with utf-8 characters fails export to PDF
> http://qa.openoffice.org/issues/show_bug.cgi?id=115788
>
> So far no one else can reproduce it.
I can. Its a problem in vcl/source/gdi/pdfwriter_impl.cxx and
DECODE_WITH_CHARSET.
We now always write as US_ASCII to pdf now, which is one change from
3.2.1, so pretty much anything with DECODE_WITH_CHARSET in that file is
very dubious unfortunately.
The attached two alternative fixes would fix it for me. Either don't
decode URIs and leave %XX in them (This might adversely affect the
"Launch" target, whatever that exactly does in PDF), or assume that we
can write as UTF-8 always. Probably need to go read the pdf spec to see
what's the correct option here.
C.
diff --git a/vcl/source/gdi/pdfwriter_impl.cxx b/vcl/source/gdi/pdfwriter_impl.cxx
index b3679aa..693d8ef 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -4665,7 +4667,7 @@ we check in the following sequence:
//substitute the fragment
aTargetURL.SetMark( aLineLoc.getStr() );
}
-rtl::OUString aURL = aTargetURL.GetMainURL( (nSetRelative || eTargetProtocol == INET_PROT_FILE) ? INetURLObject::DECODE_WITH_CHARSET : INetURLObject::NO_DECODE );
+rtl::OUString aURL = aTargetURL.GetMainURL( INetURLObject::NO_DECODE );
// check if we have a URL available, if the string is empty, set it as the original one
// if( aURL.getLength() == 0 )
// appendLiteralStringEncrypt( rLink.m_aURL , rLink.m_nObject, aLine );
diff --git a/vcl/source/gdi/pdfwriter_impl.cxx b/vcl/source/gdi/pdfwriter_impl.cxx
index b3679aa..bc4ecca 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -69,6 +69,8 @@
#include
#include
+#include
+
using namespace vcl;
using namespace rtl;
@@ -2008,7 +2010,7 @@ inline void PDFWriterImpl::appendLiteralStringEncrypt( const rtl::OString& rInSt
inline void PDFWriterImpl::appendLiteralStringEncrypt( const rtl::OUString& rInString, const sal_Int32 nInObjectNumber, rtl::OStringBuffer& rOutBuffer )
{
-rtl::OString aBufferString( rtl::OUStringToOString( rInString, RTL_TEXTENCODING_ASCII_US ) );
+rtl::OString aBufferString( rtl::OUStringToOString( rInString, RTL_TEXTENCODING_UTF8 ) );
appendLiteralStringEncrypt( aBufferString, nInObjectNumber, rOutBuffer);
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] http://libreoffice.boldandbusted.com/ cppcheck report server problem
Le 29/11/2010 14:38, Julien Nabet a écrit : Hello, I reproduced the segmentation fault with the same file (blibs-gui/vcl/source/helper/canvasbitmap.cxx) by activating "enable=all" for cppcheck. I made a tracker on cppcheck (#2252 http://sourceforge.net/apps/trac/cppcheck/ticket/2252). Julien. Hello, Just to say that this tracker is solved now and that another tracker, the #2248: (memory leak : pointer inserted in an object, ex in the file ./libs-gui/svl/source/items/aeitem.cxx). Jesse, could you give another try to it if you have time ? Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)
regards
>From f5aac0dd10c586fbcdcd8e6a86e396601db8ad27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?=
Date: Mon, 29 Nov 2010 08:20:37 +0100
Subject: [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)
---
.../source/core/unocore/sw_SwXTextDefaults.cxx |8 ++--
binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx | 17 ---
binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx |9 ++-
.../bf_sw/source/core/unocore/sw_unofield.cxx | 24 ++---
.../bf_sw/source/core/unocore/sw_unoframe.cxx | 16 +++---
binfilter/bf_sw/source/core/unocore/sw_unoftn.cxx | 16 +++---
binfilter/bf_sw/source/core/unocore/sw_unoidx.cxx | 32 +---
binfilter/bf_sw/source/core/unocore/sw_unoobj.cxx | 16 +--
.../bf_sw/source/core/unocore/sw_unorefmk.cxx | 12 ++--
binfilter/bf_sw/source/core/unocore/sw_unosect.cxx | 22 +
binfilter/bf_sw/source/core/unocore/sw_unosett.cxx | 50 +++-
11 files changed, 133 insertions(+), 89 deletions(-)
diff --git a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
index 14e8028..c1acdb5 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
@@ -166,28 +166,28 @@ Any SAL_CALL SwXTextDefaults::getPropertyValue( const OUString& rPropertyName )
}
-void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& xListener )
+void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*xListener*/ )
throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
{
DBG_WARNING ( "not implemented" );
}
-void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*aListener*/ )
throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
{
DBG_WARNING ( "not implemented" );
}
-void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
{
DBG_WARNING ( "not implemented" );
}
-void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
{
DBG_WARNING ( "not implemented" );
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
index 98d174d..fead095 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
@@ -275,7 +275,7 @@ uno::Reference< beans::XPropertySetInfo > SwXBookmark::getPropertySetInfo(void)
return aRef;
}
-void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& aValue)
+void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& /*aValue*/)
throw( beans::UnknownPropertyException, beans::PropertyVetoException,
lang::IllegalArgumentException, lang::WrappedTargetException, uno::RuntimeException )
{
@@ -294,25 +294,26 @@ uno::Any SwXBookmark::getPropertyValue(const OUString& rPropertyName) throw( bea
return aRet;
}
-void SwXBookmark::addPropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::addPropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
{
}
-void SwXBookmark::removePropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::removePropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
{
}
-void SwXBookmark::addVetoableChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::X
[Libreoffice] En Ünlü Markalar En Uygun Fiyatl arla
Yeni Sayfa 1 ANA SAYFA İNDİRİMLİ ÜRÜNLER Yeni Eklenen Ürünler Alışveriş Sepetim İletişim Bilgilerimiz ÜRÜNLER Sütyen Sütyen-Külot Takım Atlet/Body Garson Sütyen Atlet-Külot ve Body Takım Külot/Tanga, String Short Babydoll Gecelik ve Sabahlık Pijama Kombinezon ve Jupon Çorap-Jartiyer Vücut Çorabı Tayt Korse Büstiyer Hamile-Emzirme Gelin Fantezi Ürünler-Kostüm ERKEK - Atlet Külot Boxer ERKEK - Pijama Diğer Ürünler Pop-up Slip (Destekli) Gömlek Pijama Takım Barbie Babydoll Toparlayıcı Dantelli Sütyen Amerikan Yaka T-shirt Push Up Sütyen 2'li Pijama Set (S-M-L-XL) Dikişsiz Short Korse Fit 15 Pantolon Çorabı Felina Sütyen Babydoll (Bihter Geceliği) Sporcu Sütyeni
Re: [Libreoffice] [UX] LO status bar annoyances
On Tue, 2010-11-30 at 19:44 +0100, Cor Nouws wrote: > Hi Kohei, > > Kohei Yoshida wrote (30-11-10 17:25) > > > [...] > > Removing that would > > not radically improve the real estate of the status bar. > >Indeed. >Plus that I guess there are quite some interesting Calc/Excel issues > out there, waiting for 'some love', as Thorsten always can say so kindly. > >As you wrote in another mail (and rewritten a bit by me): the smaller > the control, the stronger the feelings seem to be ;-) :-) Well, all I'm trying to do is to make sure that whoever will make the decision understand the rationale and background behind the placement of the document modified icon in the status bar. I've done what I did based of several iterations of trials and errors, lots of discussions with the Oracle folks & some vocal OOo users, lots of bug reports filed etc etc etc. So the decision was not made in some random fashion. As long as that's understood, and if we still believe that icon needs to go, then I'm fine with it. I would personally be disappointed for sure, but we are here for the greater vision. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Kohei Yoshida changed: What|Removed |Added Depends on||31805 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
Hi Joe, Joe Smith wrote (30-11-10 18:30) I think Sebastian has raised a number of good points. Forcing users to deal with stuff that only experts care about is a huge problem with OOo; I sincerely hope LibO can do better. Information given by the status bar, plus the control options it gives, often is important for users I advise. That are users that do more than copy paste - Ctrl-A - set font size and name, yes. But really expert .. that is only a part of them. Regards, Cor -- - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Hi Kohei, Kohei Yoshida wrote (30-11-10 17:25) [...] Removing that would not radically improve the real estate of the status bar. Indeed. Plus that I guess there are quite some interesting Calc/Excel issues out there, waiting for 'some love', as Thorsten always can say so kindly. As you wrote in another mail (and rewritten a bit by me): the smaller the control, the stronger the feelings seem to be ;-) Cor -- - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Script to find undocumented classes
On Tue, Nov 30, 2010 at 04:21:08PM +0100, Thorsten Behrens wrote: > Miklos Vajna wrote: > > Does the idea sounds sane, OK to push? > > > Totally! OK, pushed. > Would you maybe also be interested to work on an improved > start page / index, e.g. like this here: > > http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/docsrc/index.dxx > > (see > http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/include/vigra/matrix.hxx > for how defgroup / ingroup etc. could be used)? Hm, sure - but I guess that in general needs a general knowledge of at least a whole module, which is not really the case for me. Or you mean a group for each subdirectory, which is probably something I can do? :) > Additionally, I think most classes don't necessarily need detailed > docs for all methods in the first place (which may also hurt later > merging from OOo), but would already benefit from a two-line > "mission statement" at class level (of course plus some module-level > overview of "what's inside"). Yes, I think it's more important to have a mission statement for a lot of classes than a few fully documented ones. :) That's what the script does - normally doxygen emits tons of warnings and this way it's easy to search for classes where there isn't a single line of doxygen comment at all. OTOH in the long run I agree with Lubos that it would be nice to have methods documented as well, unless that makes merging really hard. (I don't think it makes merging harder than comment cleanup does.) pgpmM6ovrCaE8.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 2010-11-30 at 12:30 -0500, Joe Smith wrote: > On 11/30/2010 09:54 AM, Kohei Yoshida wrote: > > > > Sorry I have to disagree there. I'm the one who put that icon there, > > and the reason for that was to have a visually obvious way to tell > > whether or not the document is currently modified. A lot of people were > > using the save icon status for that purpose, but some users (including > > myself) also didn't like the fact that you can't always save the > > document especially when the app *thinks* it's not modified (note: there > > are times when the document is marked unmodified, but some data are > > modified such as the cursor position, zoom level etc.). > > > > In response to this, LibreOffice provides a configuration option... > > Is there a use case to justify exposing any of this to users? Can you expand on what you mean by 'any of this'? > From what I've seen, users only expect one thing: a way to reliably > save their work. Yes, and to me it's equally important to give the users the ability to save the document regardless of whether or not the app *thinks* the document is modified (which is often wrong in some circumstances). > A "force save" function could be useful in some unusual situations, but > it's only interesting to experts. Nobody is talking about "forced save" here. You still have to hit Ctrl-S to save the document. We are talking about always *enabling* the save action. KOhei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Script to find undocumented classes
On Tuesday 30 of November 2010, Thorsten Behrens wrote: > Additionally, I think most classes don't necessarily need detailed > docs for all methods in the first place (which may also hurt later > merging from OOo), but would already benefit from a two-line > "mission statement" at class level (of course plus some module-level > overview of "what's inside"). I beg to differ. After having years of experience using a nice, intuitive and well-documented APIs (Qt,KDE), and being used to that, I sometimes rather suffer getting familiar with this codebase. Most APIs are not documented at all (or at most poorly, or in German, which is about the same in practice for many people). This is futher made worse by some APIs not being very intuitive (cryptic abbreviations, unclear naming, obsolete idiosyncracies, duplication, basic things being needlessly complicated). This could be a significant factor for new possible contributors. While patches removing dead code or similar certainly help too, the codebase can move forward only by people writing new code, and that requires understanding of the existing code. So I find any suggesting that docs are not necessary (or valueing merging higher) to be eventually shooting ourselves in the foot. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
Hi John, On Tue, 2010-11-30 at 04:09 -0800, John LeMoyne Castle wrote: > Hi Noel, > Sorry about the whitespace problem. Is it because I cleaned up the header > formatting? I would regenerate the patch but I don't understand clearly what > the whitespace problem is. Please let me know what I did wrong. Don't know if you did anything wrong as such just that the reformatting and reorderings of various things ( like format of some macros ) position of data definitions in the SbxValues data struct etc. make lots of noise for trivial changes. just takes more a little more time to unravel :-) > > There are at least two more iz issues - they are in the primary commit > header: 54049, 91121, > There are also others closed as dups that may have more test cases. Look at > any op with operands near or results just above (2^31)/1 or 2^31. There > are a few 100k of examples in the test sheets for Beta3 in CurTestODS.ods. good to know, thanks again Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
> From what I've seen, users only expect one thing: a way to reliably > save their work. Of course, that is just because users of traditional desktop OSes have learned it the hard way that you need to "save" your document often in order to avoid data loss in case of crashes and whatnot. In environments that have dared leave this whole document being edited vs. file in file system paradigm, like most (?) iOS apps, and probably also other mobile OS apps, there is no separate "save" functionality. And users seem to like it very much. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Crazy Ideas] Discuss
On 11/29/2010 07:48 PM, Mattias Johnsson wrote: On 30 November 2010 11:34, Joe Smith wrote: I was also having a lot of trouble learning anything from running OOo under gdb. Gdb was acting weird and I couldn't step through the code and poke around. I ended up trying to do it by adding a printf, rebuild, run, rinse, repeat. No fun; less progress. Did you turn off compiler optimisations? I had the same problem (gdb hopping around in a non-intuitive way, and the values of some useful variables were optimised out) until I turned them off. If that's the problem, you can do it by configuring with --enable-debug, or if you're just building a single module you can do "build -- debug=t dbglevel=2" I think "dbglevel=1" also turns them off, and will give less noise, but I haven't checked. Cheers, Mattias Whee! I was resisting another full build; I didn't realize this was part of the problem. Thanks! http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On 11/30/2010 09:54 AM, Kohei Yoshida wrote: Sorry I have to disagree there. I'm the one who put that icon there, and the reason for that was to have a visually obvious way to tell whether or not the document is currently modified. A lot of people were using the save icon status for that purpose, but some users (including myself) also didn't like the fact that you can't always save the document especially when the app *thinks* it's not modified (note: there are times when the document is marked unmodified, but some data are modified such as the cursor position, zoom level etc.). In response to this, LibreOffice provides a configuration option... Is there a use case to justify exposing any of this to users? From what I've seen, users only expect one thing: a way to reliably save their work. A "force save" function could be useful in some unusual situations, but it's only interesting to experts. Provide it as a function that can be bound if needed, or just use Save As and don't change the name. Some feedback as to whether the save request was completed is nice but optional. If present, it should be unobtrusive and not (permanently) shown on the status bar. A mysterious but attention-grabbing icon definitely seems a step in the wrong direction. I think Sebastian has raised a number of good points. Forcing users to deal with stuff that only experts care about is a huge problem with OOo; I sincerely hope LibO can do better. http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nominating bug 32002 as blocker for LibO-3.3.0 RC2
On Tue, 2010-11-30 at 16:58 +, Caolán McNamara wrote: > On Tue, 2010-11-30 at 10:24 -0500, Kevin Hunter wrote: > > Hullo List, > > > > Per Yi Fan Jiang's message 3 days ago, I'm nominating this bug for a > > blocker for RC2 > > I took a little look at that. What *I* see is that its broken on master, > but looks ok on libreoffice-3.3. What versions did you compare between. > Were they definitely both libreoffice-3.3 ? Indeed, libreoffice-3-3 seems to handle this correctly, both on 32 and 64-bit. And the latest master build indeed choked on this even on the 32-bit build, so I'm certain this has nothing to do with the platform as Caolan pointed out. I guess we can remove this from the list of blockers for 3.3. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Bug 31865 depends on bug 31938, which changed state. Bug 31938 Summary: Win32 installer is not BrOffice branded https://bugs.freedesktop.org/show_bug.cgi?id=31938 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nominating bug 32002 as blocker for LibO-3.3.0 RC2
On Tue, 2010-11-30 at 10:24 -0500, Kevin Hunter wrote: > Hullo List, > > Per Yi Fan Jiang's message 3 days ago, I'm nominating this bug for a > blocker for RC2 I took a little look at that. What *I* see is that its broken on master, but looks ok on libreoffice-3.3. What versions did you compare between. Were they definitely both libreoffice-3.3 ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Last patch to clean code at writer [source/ui]
thanks for your review. revol_. --- Em ter, 30/11/10, David Tardon escreveu: De: David Tardon Assunto: Re: [Libreoffice] [PUSHED] Last patch to clean code at writer [source/ui] Para: libreoffice@lists.freedesktop.org Data: Terça-feira, 30 de Novembro de 2010, 15:47 On Tue, Nov 30, 2010 at 04:46:47PM +0100, David Tardon wrote: > I retained some hunks that IMHO have documentary value. > ... and pushed the rest, too .-) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
On Tue, 2010-11-30 at 16:42 +0100, Regina Henschel wrote: > Hi Thorsten, > > Thorsten Behrens schrieb: > > Kohei Yoshida wrote: > >>>b) We warn when closing a modified doc anyway, so there is no need to > >>> always warn me and use up precious space. I propose to just do away > >>> with it. > >> > >> Sorry I have to disagree there. I'm the one who put that icon there, > >> and the reason for that was to have a visually obvious way to tell > >> whether or not the document is currently modified. > >> > > Hi Kohei, > > > > ok, but maybe there are other means to get that info across? The > > status bar, generally, uses up precious horizontal screen real > > estate, for very little benefit. > > I too think, that this info can be removed from the status bar. But if > the save icon in the symbol bar is always enabled, a new place is > needed. Many applications on WinXp set an asterix in the title bar. Is > that possible on other OS too? I too think that the title bar would be the most logical place to put this info if we were to find a replacement location. But I'm not sure if it can be easily identified by those users who currently rely on the save icon status. The save icon is big and obvious, whereas an '*' in the title bar is not as equally obvious. Also, not all Windows apps follow this practice, the most significant one being MS Office, though in MS Office's case, it doesn't show document modified status *at all*, anywhere. In fact, none of the standard apps in Windows 7 (notepad, wordpad, paint etc) show asterisks at all. The only app that still shows asterisks are Vistual Studio 2010, though not in the title bar but in the file name tab. BTW, I guess I'm the only one who thinks that the status bar is the most logical place to put the document status info? To me, some of the other tools currently on the status bar are not logically placed, but I do find the document status logically fit in there. Plus it's the smallest of all the controls currently on the status bar. Removing that would not radically improve the real estate of the status bar. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
Hi John, On Tue, 2010-11-30 at 01:35 -0800, John LeMoyne Castle wrote: > Nothing says 'run away' like mangling the money numbers. :-) > The attached CurTestODS.ods spreadsheet Basic program CurTestRunAll > demonstrates the errors from the old implementation: > -- flagrantly wrong values from string inputs > -- hugely wrong values from MDAS calculation Wow - it would be just wonderful to turn that into some run-time unit test, that we can automatically execute during the build :-) Did you see the sc/qa/unit/ code for fiddling with calc ? I suppose we could use a simpler CppUnit unit test (hopefully without the UNO mess) inside basic/ ? If we have the skeleton there, it gives much more confidence for re-factoring I think. > All of the PostFix result sheets show a great reduction in the number of > errors over Beta3 when the new implementation is used. This is really great work; looking forward to Noel's review. > I thought this would be easy - and it was easy and fun - it was > just a real Big Easy... That's just great :-) Thanks ! Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Kohei Yoshida changed: What|Removed |Added Depends on|31805 | --- Comment #17 from Kohei Yoshida 2010-11-30 08:02:31 PST --- Nominating Bug 31805 as a blocker. It's a simple little thing, but it is a regression, and has been a long standing bug since the Go-OO time. I'd like to fix it once and for all. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 2010-11-30 at 10:34 -0500, Kevin Hunter wrote: > At 9:54am -0500 Tue, 30 Nov 2010, Kohei Yoshida wrote: > > Sorry I have to disagree there. I'm the one who put that icon there, > > and the reason for that was to have a visually obvious way to tell > > whether or not the document is currently modified. A lot of people > > were using the save icon status for that purpose, but some users > > (including myself) also didn't like the fact that you can't always > > save the document especially when the app *thinks* it's not modified > > (note: there are times when the document is marked unmodified, but > > some data are modified such as the cursor position, zoom level > > etc.). > > Guilty as charged. That's how I've historically known if it's time to > save. (Because I can't be bothered to remember if I've done anything, > right?! ;-) ) But seriously, when I'm at a lull in thinking, I'll > glance there because I'm wary of the (historically) fairly regular > crashes of OO/LO and don't want to lose too much work. I think I was > aware that the status icon was there, but it's not in my repertoire to > look there because it's somewhat hard to find (takes me a second to find > it, as opposed to the bigger, more distinct icon in the upper left). Well, I'm not sure if it's *that* hard to find. I myself find it easy enough to see the lower middle part of the window in the corner of my eye. :-) Sebastian even found it annoying enough, which tells us that it was rather close to being "right in your face" for him. ;-) BTW, it was originally a simple textural '*' in that small window of the status bar, which was pretty much ignored by almost all users that I've come in contact with. > Would not one response be that the logic behind the enabling/disabling > of the save button ought to be updated? Sure, any suggestions are welcome for this. > If a document can be saved, the > save button ought to be enabled, yes? Absolutely. And when the document can be always saved, the icon remains enabled at all times. But many users didn't like that and started filing bugs left and right for it. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Last patch to clean code at writer [source/ui]
On Tue, Nov 30, 2010 at 04:46:47PM +0100, David Tardon wrote: > I retained some hunks that IMHO have documentary value. > ... and pushed the rest, too .-) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Last patch to clean code at writer [source/ui]
I retained some hunks that IMHO have documentary value. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Hi Thorsten, Thorsten Behrens schrieb: Kohei Yoshida wrote: b) We warn when closing a modified doc anyway, so there is no need to always warn me and use up precious space. I propose to just do away with it. Sorry I have to disagree there. I'm the one who put that icon there, and the reason for that was to have a visually obvious way to tell whether or not the document is currently modified. Hi Kohei, ok, but maybe there are other means to get that info across? The status bar, generally, uses up precious horizontal screen real estate, for very little benefit. I too think, that this info can be removed from the status bar. But if the save icon in the symbol bar is always enabled, a new place is needed. Many applications on WinXp set an asterix in the title bar. Is that possible on other OS too? kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Fedora-specific hyperlink bug?
Can someone running LibO on Fedora try and reproduce this bug: document hyperlink with utf-8 characters fails export to PDF http://qa.openoffice.org/issues/show_bug.cgi?id=115788 So far no one else can reproduce it. Hardly a showstopper, but it would be an embarrassing regression if it happens on systems other than mine. I see the same problem with LibO m12 beta. I can't imagine what might make this specific to the host platform--any ideas? Could something like this be a font issue? http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
At 9:54am -0500 Tue, 30 Nov 2010, Kohei Yoshida wrote: Sorry I have to disagree there. I'm the one who put that icon there, and the reason for that was to have a visually obvious way to tell whether or not the document is currently modified. A lot of people were using the save icon status for that purpose, but some users (including myself) also didn't like the fact that you can't always save the document especially when the app *thinks* it's not modified (note: there are times when the document is marked unmodified, but some data are modified such as the cursor position, zoom level etc.). Guilty as charged. That's how I've historically known if it's time to save. (Because I can't be bothered to remember if I've done anything, right?! ;-) ) But seriously, when I'm at a lull in thinking, I'll glance there because I'm wary of the (historically) fairly regular crashes of OO/LO and don't want to lose too much work. I think I was aware that the status icon was there, but it's not in my repertoire to look there because it's somewhat hard to find (takes me a second to find it, as opposed to the bigger, more distinct icon in the upper left). Would not one response be that the logic behind the enabling/disabling of the save button ought to be updated? If a document can be saved, the save button ought to be enabled, yes? (Note, I'm strategically not making any statement about the icon. :-) yet.) Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Nominating bug 32002 as blocker for LibO-3.3.0 RC2
Hullo List, Per Yi Fan Jiang's message 3 days ago, I'm nominating this bug for a blocker for RC2, after minimal discussion with Kohei and Michael via email and IRC. (Note: that's RC2, not RC1.) I don't know how to do that with the current version or this community/bug tracker, so I'm leaving the actual marking for someone more in the know. (But I'll observe!) Now, since this is for RC2, not RC1, should I still update ping Bug 31865? Cheers, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
On Tue, 2010-11-30 at 16:11 +0100, Thorsten Behrens wrote: > Kohei Yoshida wrote: > > > b) We warn when closing a modified doc anyway, so there is no need to > > > always warn me and use up precious space. I propose to just do away > > > with it. > > > > Sorry I have to disagree there. I'm the one who put that icon there, > > and the reason for that was to have a visually obvious way to tell > > whether or not the document is currently modified. > > > Hi Kohei, > > ok, but maybe there are other means to get that info across? Sure, if you have any good suggestions. > The > status bar, generally, uses up precious horizontal screen real > estate, for very little benefit. Well, status bar contains info about status, and document modified "status" fits the bill, no? ;-) > -- Thorsten, who likes the '*' prefix on the window title bar Indeed, but just to put this in prospective, I've received tons of angry emails from users when I suggested to always enable the save icon. They also said that things like a small '*' in the title bar would not be obvious enough. Obviously many users feel very *emotional* about this issue, and I found it out the hard way. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
Hi Sebastian, Sebastian Spaeth schrieb: Am I the only one finding the current status bar pretty much useless? Yes ;) To learn more about the status bar have a look at http://www.ooowiki.de/StatusLeiste. It is in German and needs an update, but the text shows, that the status bar is a great tool. To get all the nice extended tips, I have added the button "Extended Tips" (German "Aktive Hilfe") (category "Application") to the symbol bar, so that I can switch it easily on and off. kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Script to find undocumented classes
Miklos Vajna wrote: > Does the idea sounds sane, OK to push? > Totally! Would you maybe also be interested to work on an improved start page / index, e.g. like this here: http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/docsrc/index.dxx (see http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/include/vigra/matrix.hxx for how defgroup / ingroup etc. could be used)? Additionally, I think most classes don't necessarily need detailed docs for all methods in the first place (which may also hurt later merging from OOo), but would already benefit from a two-line "mission statement" at class level (of course plus some module-level overview of "what's inside"). Cheers, -- Thorsten pgppVNIlYFzxW.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Kohei Yoshida wrote: > > b) We warn when closing a modified doc anyway, so there is no need to > > always warn me and use up precious space. I propose to just do away > > with it. > > Sorry I have to disagree there. I'm the one who put that icon there, > and the reason for that was to have a visually obvious way to tell > whether or not the document is currently modified. > Hi Kohei, ok, but maybe there are other means to get that info across? The status bar, generally, uses up precious horizontal screen real estate, for very little benefit. Cheers, -- Thorsten, who likes the '*' prefix on the window title bar pgpMIFImfekSm.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion needed for External Edit functionality.
Hi everyone, After few sleepless nights spent grokking and with quite a big deal help from IRC and the list, have come up with the first cuts working version of the External Edit functionality[1]. Have attached the patches rebased against the latest master. Would love to hear reviews/suggestions/improvements :) PS And I had lots of fun hacking. [1] https://bugs.freedesktop.org/show_bug.cgi?id=30508 On Mon, Nov 22, 2010 at 5:27 PM, Michael Meeks wrote: > -- regards Suren Learning < Doing Learn By doing. edit_external.tar.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
Hi Sebastian, On Tue, 2010-11-30 at 11:26 +0100, Sebastian Spaeth wrote: > - What annoys me most is the "document modified indicator". If it is > unmodified, I see some *empty* separators in the status bar (why do we > show empty separators? these should GO GO GO away) and the mouse > tooltip over the *empty* separator says "this document has not been > modified". When I type, I get a document with an exclamation mark, and > the tooltip changes to "this document has been modified". > > a) This is the standard state of my documents (see, I tend to modify > docs in a editor, DOH), and that exclamation mark purports some > sense of urgency and failure. > > b) We warn when closing a modified doc anyway, so there is no need to > always warn me and use up precious space. I propose to just do away > with it. Sorry I have to disagree there. I'm the one who put that icon there, and the reason for that was to have a visually obvious way to tell whether or not the document is currently modified. A lot of people were using the save icon status for that purpose, but some users (including myself) also didn't like the fact that you can't always save the document especially when the app *thinks* it's not modified (note: there are times when the document is marked unmodified, but some data are modified such as the cursor position, zoom level etc.). In response to this, LibreOffice provides a configuration option to allow users to be able to always save the current document. Turning on this option, however, leaves the save icon always enabled (and rightfully so), which to those users who were using it to see the document modified status takes away that visual clue. Hence the document modified status icon on the status bar was placed as a replacement. Some of us even think that we should turn on this option by default. Currently it's off by default. So, that's the background on this indicator. I'm afraid we can't remove this unless there is really really good reason to do so. ;-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Kohei Yoshida changed: What|Removed |Added Depends on||31805 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 2010-11-30 at 12:12 +0100, Sebastian Spaeth wrote: > 2) Remove the Selection mode thing. Unless people are really using > that. I use it. Probably not often enough to warrant it being on the status bar permanently, but it does get used. Nigel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Rainer Bielefeld changed: What|Removed |Added Depends on|31734 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Script to find undocumented classes
Hi, I'm attaching a patch that adds a script to the scratch directory of a build repo that tries to find undocumented classes using doxygen. It's meant to be invoked in a subdirectory of the source code, so in case one is familiar with Calc, she can run it under sc/ and add doxygen comments to the classes she know, etc. I'm intentionally not using 'make docs', because the target here is to allow quick iteration, ie. to run 'find-undocumented-classes.sh -q' in a subdirectory, add a few comments, run again, etc. Does the idea sounds sane, OK to push? Thanks. From 0fd0d400e3a64cb9619a207868c835d18acce162 Mon Sep 17 00:00:00 2001 From: Miklos Vajna Date: Mon, 22 Nov 2010 14:33:57 +0100 Subject: [PATCH] Add script to find undocumented classes --- scratch/find-undocumented-classes.sh | 26 ++ 1 files changed, 26 insertions(+), 0 deletions(-) create mode 100755 scratch/find-undocumented-classes.sh diff --git a/scratch/find-undocumented-classes.sh b/scratch/find-undocumented-classes.sh new file mode 100755 index 000..58a133b --- /dev/null +++ b/scratch/find-undocumented-classes.sh @@ -0,0 +1,26 @@ +#!/bin/bash + +# finds undocumented classes in the current directory (recursive) + +filter= +quiet=n +if [ "$1" = "-q" ]; then +filter=">/dev/null" +quiet=y +fi + +doxygen=$(mktemp -d) +eval doxygen -g $doxygen/doxygen.cfg $filter +sed -i "/HTML_OUTPUT/s|html|$doxygen/html|" $doxygen/doxygen.cfg +sed -i '/GENERATE_LATEX/s/= YES/= NO/' $doxygen/doxygen.cfg +sed -i '/RECURSIVE/s/= NO/= YES/' $doxygen/doxygen.cfg +eval doxygen $doxygen/doxygen.cfg $filter 2> $doxygen/errors.txt +if [ "$quiet" == "n" ]; then +echo +echo "The following classes are undocumented:" +echo +fi +cat $doxygen/errors.txt|grep 'Warning: Compound.*is not documented' +rm -rf $doxygen + +# vim:set shiftwidth=4 softtabstop=4 expandtab: -- 1.7.3.2 pgpH5wsBDaPkn.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated artwork for RC
Hi Thorsten, On Tue, 2010-11-30 at 00:31 +0100, Thorsten Behrens wrote: > default_images/framework/res/backing.png > default_images/framework/res/backing_hc.png I don't believe we use these anymore; it would be great to remove them all on master if you could :-) > default_images/brand/shell/backing.png > default_images/brand/shell/backing_hc.png We should drop all the hc variants in there too (if you would). > default_images/introabout/about.png > default_images/introabout/about.bmp > default_images/introabout/intro.png > default_images/introabout/intro.bmp I removed these (at least on master) some days ago. > default_images/brand/introabout/about.png > default_images/brand/introabout/about-pt_BR.png > default_images/brand/introabout/intro.png > default_images/brand/introabout/intro-pt_BR.png The above are the live ones > instsetoo_native/inc_ooolangpack/windows/msi_templates/Binary/Banner.bmp There is a lot of cruft here; we should move it all to default_images/brand/ IMHO. > setup_native/source/win32/nsis/ooosdkbanner.bmp > setup_native/source/win32/nsis/brosdkbanner.bmp Same for this lot - -but- I'm working on the NSIS stuff around this just now - so please be patient ;-) there was a lot of obsolete artwork in this directory too let me get that at least :-) HTH, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
More About the Tester -- CurTestODS.ods :: Standard :: CurTestRunAll : Most of the fix has been done for over a week, but a Basic test program was required to identify the existing errors, to sort out the scaling factor application and to demonstrate that the fix does not completely break Basic. It took some effort to get a Basic program that did all the calculations on scalar variables at the usual sub scope (partly to avoid issues reported with Currency in array/as param). Several refactorings were done to handle run-time errors, to add more types and to prevent too much ugly copy-and-paste bloat. The mind-numbing explicitness seems necessary to create a thorough fundamental test of just a little part of the language. The existing issues were general enough to need to test ~all types and math operations that could produce a Currency value. I think Basic can only be well tested in Basic. While it is possible that a similar test program has already been written, it is fairly obvious that this kind of test hasn't been run on the Currency type in a while. All permutations of operand types were tested because the Basic run-time expression evaluation may change the type depending on other operand's type and left or right position. Sadly, this test does not completely demonstrate that the fix does not break Basic in some way. The test sheet is offered as a prototype for a unit test on one Basic language type. A set of similar tests would be useful to anyone hacking on the Basic innards. -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Basic-Currency-Issues-i31001-to-i107277-tp1991648p1992294.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
Hi Noel, Sorry about the whitespace problem. Is it because I cleaned up the header formatting? I would regenerate the patch but I don't understand clearly what the whitespace problem is. Please let me know what I did wrong. There are at least two more iz issues - they are in the primary commit header: 54049, 91121, There are also others closed as dups that may have more test cases. Look at any op with operands near or results just above (2^31)/1 or 2^31. There are a few 100k of examples in the test sheets for Beta3 in CurTestODS.ods. The CurTestODS.ods will allow you to throw any numbers you like at the currency type by placing them on the CurTestMeta sheet. I wrote the tester because the iz examples were not all reproducible but there were still obvious similar problems with the type but of unknown extent and character. Try the Demo test which is in CurTestMeta sheet and so it will be done if you run CurTestRunAll in the tester ods. One can place their own input sets in CurTestMeta: use the OneCol[Square] IB/TB tags for N^2 pairs or give a list of pairs with TwoCol tags on IB and TB [Input Block and Test Block] or just hack the existing tests to try other values. Can hack the test program to set OnlyPrintError = False and see all the test results good, bad and overflow - the test runs slower that way. The CurTestRunAll program always does the tests on CurTestMeta and writes to the CurTestResults sheet. You need a CurTestResults sheet and it can be helpful to manually clear the results sheet between tests. For others who want to try the testing or just look at the test results in the sheet and are unsure how: 1) Download, unpack and open the ods 2) If you do not have macros enabled then do that in Options-Security and re-open the sheet. 3) Alt-F11 opens the organizer - choose CurTestODS - Standard - CurrencyTest then - CurTestRunAll and Run to Run it. - or CurTestRunAll and Edit then use F5 to run when the cursor is at file scope or in CurTestRunAll (at the top of the file). -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Basic-Currency-Issues-i31001-to-i107277-tp1991648p1992291.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
sending again ( whilst attempting to preserve the threading this time ) On Tue, 2010-11-30 at 01:35 -0800, John LeMoyne Castle wrote: > OOo Basic has had issues with its fixed point Currency type for a long time. > I think the Basic Currency type deficiencies create a bar to adoption in the > minds of business users. > Nothing says 'run away' like mangling the money numbers. Agreed !! and thanks for looking at this > > Currency is presently implemented with a 64bit struct of 2 Int32s and the > math is done by the tools/bigint class. > The attached patches replace the code to implement the Currency type with an > ISO C99 compiler supported 64 bit integer. > In fact, the 64 bit int was already a member of the Sbx core data union. > Main patch makes 1/2 kLOC reduction in sbx. yeah, so you will have to give me some time to look at this ( not really familar with the Currently type ) and I need to somehow filter out the whitespace changes too ( probably I can regenerate the patch to do that. ) regards, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
On Tue, 2010-11-30 at 01:35 -0800, John LeMoyne Castle wrote: > OOo Basic has had issues with its fixed point Currency type for a long time. > I think the Basic Currency type deficiencies create a bar to adoption in the > minds of business users. > Nothing says 'run away' like mangling the money numbers. Agreed !! and thanks for looking at this > > Currency is presently implemented with a 64bit struct of 2 Int32s and the > math is done by the tools/bigint class. > The attached patches replace the code to implement the Currency type with an > ISO C99 compiler supported 64 bit integer. > In fact, the 64 bit int was already a member of the Sbx core data union. > Main patch makes 1/2 kLOC reduction in sbx. yeah, so you will have to give me some time to look at this ( not really familar with the Currently type ) and I need to somehow filter out the whitespace changes too ( probably I can regenerated the patch to do that. regards, Noel p.s. are you aware of more iz issues related to this other than the 2 mentioned in the subject? be good to have as much test data as possible ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Crazy Ideas] Discuss
On Mon, Nov 29, 2010 at 08:21:08PM -0500, Kohei Yoshida wrote: > > If that's the problem, you can do it by configuring with > > --enable-debug, or if you're just building a single module you can do > > "build -- debug=t dbglevel=2" > > "build debug=t" alone should turn off compiler optimization, before the > '--' not after. I wouldn't recommend dbglevel=2 unless you know what > you are getting with dbglevel=2. > > > I think "dbglevel=1" also turns them off, and will give less noise, > > but I haven't checked. > > It's the debug=t part that turns off compiler optimization. dbglevel=# > controls the amount of debug messages that other devs have put in (if I > understand David's mail correctly, that is). > Correct. Note that you can also use nopt=true if you don't want debug build (but why wouldn't you? .-) That just turns off optimization. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On Tue, 30 Nov 2010 11:26:54 +0100, Sebastian Spaeth wrote: > Am I the only one finding the current status bar pretty much useless? May I propose these changes to the writer statusbar? These have been achieved by modifying a few lines of .xml and are much cleaner IMHO. See the old and the new one attached in this file (the real thing, not just a mockup): pgpp58f3dHlZi.pgp Description: PGP signature <> Changes: 1) Don't autosize the Page number, page style, and language dialog. They look much better when using just the space they need. 2) Remove the Selection mode thing. Unless people are really using that. 3) Remove that horrid page layout thing. I doubt people switch from single to double page layout that often to warrant a status bar entry. 4) Don't show zoom percentages. It doesn't really provide info in a writer doc, and we have magnetic markers for the 100% anyway. What was not easily fixable is: - Show useful tolltips for the remaining entries - Ideally make the INSRT/OVER thing just be a non-click status information thingie. Most keyboards have a dedicated key for that. - Consistently let's launch things on single or double-click but not one or the other in some cases. Review/Feedback? Sebastian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Language selection
>> I have installed just a few languages, but still "all the wrong" >> languages show up. When you say you have installed just a few languages, do you mean in the LibreOffice Windows installer? There you select what *user interface* languages are available, not what languages LibreOffice has writing aids support for. I.e. you can for instance have the LibreOffice interface in German but write a document in English, with spell checking. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Sebastian Spaeth wrote: > Am I the only one finding the current status bar pretty much useless? > Nope. I hear you, pretty much unconditionally. Adding UX tag & Cc-ing my favourite UX homie. :) Cheers, -- Thorsten pgphW56AvlvY5.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Language selection
On Mon, 2010-11-29 at 17:09 -0500, Arno Teigseth wrote: > I have installed just a few languages, but still "all the wrong" > languages show up. As far as I recall, those langauges are from the language guessing feature, and hopefully are in order of most likely language first and so on. > Could it be an idea to show the > -last used languages first > or > -installed languages first > > in that box? Sure, shouldn't be too difficult to play around with it. You can find the code around sw/source/ui/lingu/olmenu.cxx and search for LanguageGuessing If you're using the feature a lot then there's may be something rather strange with how you're working ;-) The concept is generally for the occasional time when you write a few words or paragraph in a different language than your usual one. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LO status bar annoyances
Am I the only one finding the current status bar pretty much useless? About the only thing I actually use there, is the zoom slidebar (and I wouldn't use that if I were able to have a single "set 'optimal' zoom button in my toolbar which doesn't seem possible). - What annoys me most is the "document modified indicator". If it is unmodified, I see some *empty* separators in the status bar (why do we show empty separators? these should GO GO GO away) and the mouse tooltip over the *empty* separator says "this document has not been modified". When I type, I get a document with an exclamation mark, and the tooltip changes to "this document has been modified". a) This is the standard state of my documents (see, I tend to modify docs in a editor, DOH), and that exclamation mark purports some sense of urgency and failure. b) We warn when closing a modified doc anyway, so there is no need to always warn me and use up precious space. I propose to just do away with it. - I have to single-click on the INSRT and STD->EXT->ADD->BLK and language selection thingies, but to double-click on the Page 1/1 and "Default" for something to happen. I just found out by coincidence today that I can launch some action for the latter. - Despite being a heavy writer user, I have no clue what EXT/ADD/BLK mean, or what they are being used for (so I never use it). They have no tooltip whatsoever to give me a clue either. The toolbar help button unfortunately launches the generic help, rather then the more useful "what's this". In a "what's this" mode, I do see a tooltip help (why not always), saying this is about the selection mode. What the selection mode EXTEND, ADD, or BLOCK are, I have still no clue about. Perhaps a right-click on that thing could offer to open a more elaborate help page? (keep the tooltip always in any case). And more fundamentally, do people really change the selection style in their documents to something else? Ever? Does this really require a statusbar item? Help text: Anyway after much search I found the entry in the help page that refers to that feature. I only had to "what's this" the item, to get to know about "Selection Mode" and search the help until it discovered the "selection modes in text" item. It has very useful help. BLK means: "A block of text can be selected.". /me slaps heads. How could I not know!!1! (err, can't I select a block of text with the STD as well? How dot they differ? But that's a topic for another day :). - Randomly trying out things and clicking on an empty area in the status bar, brought up a dialog window titled "Fields" which offered me to insert the "Author"->"Name", if I get it right (playing a bit dumb here). It also has a checkbox for "Fixed content" (who doesn't want to fix there content, but that is also for another day). Anyway, clicking (actually double-clicking required this time) on an *empty* area should not open mysterious dialog boxes. Where in the code is that collection of mysteries being placed on the statusbar and should I file bugs to put this rant into :-)? Sebastian pgpIppcPxGZKt.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] High contrast issue
I am not sure about that but mordaci on irc gave me this link https://bugs.freedesktop.org/show_bug.cgi?id=31424 What is annoying is that i cant see the names of the options given when using a dark theme as it switches the text to white. LO isn't only affected by this kopete is as well, but that is unrelated to the project. what could be done to see if the theme is a dark theme so that the start will have black text instead of white? On 11/30/2010 10:44 AM, Sebastian Spaeth wrote: On Tue, 30 Nov 2010 09:28:58 +0100, Jonathan Aquilina wrote: Hey guys I am experiencing a really nasty HC issue. I am using the obsidian theme on KDE. Doesn't OOo/LO switch to Highcontrast automatically with a dark theme? I know a lot of people that would be unhappy if this were really the case. :-). Seriously, we shouldn't try to detect HC based on the window color of some theme. Sebastian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] High contrast issue
On Tue, 30 Nov 2010 09:28:58 +0100, Jonathan Aquilina wrote: > Hey guys I am experiencing a really nasty HC issue. > > I am using the obsidian theme on KDE. Doesn't OOo/LO switch to Highcontrast automatically with a dark theme? I know a lot of people that would be unhappy if this were really the case. :-). Seriously, we shouldn't try to detect HC based on the window color of some theme. Sebastian pgpTDAvxfSvr6.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
OOo Basic has had issues with its fixed point Currency type for a long time. I think the Basic Currency type deficiencies create a bar to adoption in the minds of business users. Nothing says 'run away' like mangling the money numbers. Currency is presently implemented with a 64bit struct of 2 Int32s and the math is done by the tools/bigint class. The attached patches replace the code to implement the Currency type with an ISO C99 compiler supported 64 bit integer. In fact, the 64 bit int was already a member of the Sbx core data union. Main patch makes 1/2 kLOC reduction in sbx. http://nabble.documentfoundation.org/file/n1991648/0001-Basic-Currency-64bit-impl-fixes-i31001-to--libs-core.patch.tar.gz 0001-Basic-Currency-64bit-impl-fixes-i31001-to--libs-core.patch.tar.gz http://nabble.documentfoundation.org/file/n1991648/0001-Basic-Currency-type-native-64bit-implemen-components.patch 0001-Basic-Currency-type-native-64bit-implemen-components.patch http://nabble.documentfoundation.org/file/n1991648/CurTestODS.ods.tar.gz CurTestODS.ods.tar.gz The attached CurTestODS.ods spreadsheet Basic program CurTestRunAll demonstrates the errors from the old implementation: -- flagrantly wrong values from string inputs -- hugely wrong values from MDAS calculation (where flagrantly, hugely == 10+ orders of magnitude off) -- no-op (returning one of the operands instead of doing the operation) -- incorrect overflow from operations on bad string input values -- different errors and error rates on different platforms (in LibO Beta 3 on Ubuntu10.04 and WinVista) The errors appear to start when results reach ~2.15e5 [(2^31-1)/10,000]. They continue up through the Currency upper limit of ~1e15. The errors affect all of the basic MDAS (*/+-) math operations mostly(?) add and subtract. I didn't troubleshoot the errors thoroughly because the offending code was either: ripped out and replaced with simple C++ operations on the compiler supported 64 bit int, or removed by rework of the Compute, Get and Put routines in sbx/*. The test program is CurTestODS.ods :: Standard :: CurTestRunAll CurTestRunAll tests number pairs from the CurTestMeta sheet by: -2x- reading the numbers in as strings or doubles -4x- performing all MDAS (*/+-) operations -16x- for all Basic operand type combinations of integer(16b), long (32b), double (64b) and currency for 128 tests on each number pair each test producing a Currency type result. Expected values are calculated by a parallel calculation in doubles to produce an expected Currency type result. Anticipated Basic run-time errors (overflow and div by zero) are identified and passed. Unexpected BRT errors are counted and output as errors. All of the PostFix result sheets show a great reduction in the number of errors over Beta3 when the new implementation is used. The 4 remaining "errors" in the Demo result set show both the strength and the weakness of the fixed point Currency type relative to the double precision floating point type. These type differences pre-exist by definition and will not go away in any implementation. Where more fractional digits are needed the Double is more accurate, but when more significant digits are needed the Currency type is more accurate. What else it does: The fix needed to include corrections to the currency-get-value-from-string-literal because it was a source of bad values. Users have requested in OOo issues to get the ability to use string literals in their Locale format as set in the options. The new string getter relaxes the requirement that string literal be in en-US format (i.e. "1,000,000.00") - it will now accept "1.000.000,00" if the Locale allows it while always accepting the Basic standard en-US format. The getter will also always accept (always ignore) spaces within a number string so "1 000 000.00 00" is accepted. The Locale read was lifted from another of the Currency string input functions. If this needs rework or reversion let me know. I thought this would be easy - and it was easy and fun - it was just a real Big Easy... All contributions licensed per TDF standard: MPL 1.1 / GPLv3+ / LGPLv3+ --LeMoyne (JLCastle) -- View this message in context: http://nabble.documentfoundation.org/PATCH-Basic-Currency-Issues-i31001-to-i107277-tp1991648p1991648.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] opening oxt from command line
On Mon, Nov 29, 2010 at 05:02:06PM -0500, Arno Teigseth wrote: > Hi > > I have > > LibreOffice 3.3.0 > > OOO330m9 (Build:1) > > libreoffice-build 3.2.99.2 > > > It hangs when I do "libreoffice extension.oxt" from the command line. No > error messages on stdout. > > Adding the extension from the menu Tools | Extension manager works fine. > > Arno Thanks for the report! Confirmed. I'll look into it. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
