Attention: The changes to the build system are about to be pushed....

in the next few minutes

[Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

https://bugs.freedesktop.org/show_bug.cgi?id=31865

--- Comment #18 from Kohei Yoshida <kyoshida@...> 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.

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

[Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

https://bugs.freedesktop.org/show_bug.cgi?id=31865

--- Comment #19 from Yifan <yfjiang@...> 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.

[Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

https://bugs.freedesktop.org/show_bug.cgi?id=31865

Yifan <yfjiang@...> 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.

Re: 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
<nthiebaud@...> 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

Hi,

On Tue, 30 Nov 2010 21:02:05 -0600, Norbert Thiebaud
<nthiebaud@...> 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

Re: 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 <tabe@...> wrote:
> Hi,
>
> On Tue, 30 Nov 2010 21:02:05 -0600, Norbert Thiebaud
<nthiebaud@...> 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
>

Subject: [PATCH] Accelerate perl installer: optimize installer::scriptitems::optimize_list().

[PATCH] Accelerate perl installer: optimize installer::scriptitems::optimize_list().

    Another performance improvement for the perl installer.  This one
brought my ./bin/ooinstall -l <dirname> 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

    Another performance improvement for the perl installer.  This one
brought my ./bin/ooinstall -l <dirname> 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).

Re: [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* 

Re: [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