On 11/9/2022 1:47 AM, A wrote:
I wanted to contribute to libreoffice but decided not to after I got
abused by some list members because I offered a suggestion which they
didn't like.
All I can see is that it is YOU who is abusing others. And then complain
when you're being called
Don't tell me where to contribute. I will decide that myself.
My patches are there in linux kernel. I am happy contributing to linux
kernel.
As long as MS Office is in existence, libreoffice will be considered a
failure.
I didn't hate libreoffice earlier but now I hate libreoffice because of
ego
Dear Amit, I suggest you contribute to Apache OpenOffice instead. They
are a much more welcoming bunch, and you will share the hate of
LibreOffice! They are eager to welcome new contributors.
--tml
gt; > I wanted to contribute to libreoffice but decided not to after I got
> > abused by some list members because I offered a suggestion which they
> > didn't like.
>
> That's not how things went down, though. You told a developer to fuck
> off:
> https://lists.freed
On 9.11.2022 11.47, A wrote:
I wanted to contribute to libreoffice but decided not to after I got
abused by some list members because I offered a suggestion which they
didn't like.
That's not how things went down, though. You told a developer to fuck
off:
https://lists.freed
I wanted to contribute to libreoffice but decided not to after I got
abused by some list members because I offered a suggestion which they
didn't like.
So, I thought that why should I invest my time in libreoffice when
people in libreoffice can't handle negative feedback in a dignifie
Try using Cut and Paste in the other worksheet and then paste in the
original place.
Em 23/09/2022 14:57, Kevin Suo escreveu:
Hi. My name is Matt. I use Calc a lot. I have a great idea. First, I
usually modify my spreadsheets to improve them. They are complex. But
I have a few versions of one
ltiple screen monitors attached to your computer.
*From: *Matthew Parker [mailto:matthewpark...@gmail.com]
*Sent: *Friday, September 23, 2022 08:16 AM +08
*To: *libreoffice@lists.freedesktop.org
*Subject: *Easy to do, great feature. Suggestion.
Hi. My name is Matt. I use Calc a lot. I have
You probably support https://bugs.documentfoundation.org/show_bug.cgi?id=31481
As a side note, you may benefit from the data provider.
On 23.09.22 02:16, Matthew Parker wrote:
Hi. My name is Matt. I use Calc a lot. I have a great idea...
OpenPGP_signature
Description: OpenPGP digital signature
On 23.09.2022 3:16, Matthew Parker wrote:
So if more than one sheet of the same spreadsheet could be viewed side
by side at the same time, it will make cross referencing cells between
sheets a whole lot faster.
Menu Window->New Window.
--
Best regards,
Mike Kaganski
Hi. My name is Matt. I use Calc a lot. I have a great idea. First, I
usually modify my spreadsheets to improve them. They are complex. But I
have a few versions of one type, e.g. "Schematic" which is a schematic of
my solar generator installations which has tables that calculate power
yields and wo
On 10/21/21 17:25, Luboš Luňák wrote:
On Thursday 21 of October 2021, Hossein Nourikhah wrote:
Since C++11, range based loops are available for iterating over a known
range of values. For example, when there is a need to process elements
of a container, range based loops are usually a good choic
On Thursday 21 of October 2021, Hossein Nourikhah wrote:
> Since C++11, range based loops are available for iterating over a known
> range of values. For example, when there is a need to process elements
> of a container, range based loops are usually a good choice. They are
> easy to write, read a
Hello,
This is a suggestion for adding an EasyHack with the difficulty
"Beginner". I have asked one of the newbies to do a submission regarding
this. Please tell me your opinion. I welcome any suggestions.
Regards,
Hossein
**Use range based for loops**
S
On Sat, May 23, 2020 at 9:32 AM Eivind Samseth wrote:
>
> Here’s the way you can distribute localizations on macOS
> 1. Include all localizations in the standard download (used by all Apple
> software, MS Office etc.)
> 2. Offer precompiled .app bundles in the language of choice (used by Firefox)
Am 15.06.20 um 11:33 schrieb Tor Lillqvist:
> (Sorry, my fingers slipped somehow and my previous reply had no of my
> own text.)
>
> 4) create a real macOS installer package (native macOS installer
> program, not a runnable script like the langauge pack "installer"),
> similar to the w
(Sorry, my fingers slipped somehow and my previous reply had no of my own
text.)
4) create a real macOS installer package (native macOS installer
> program, not a runnable script like the langauge pack "installer"),
> similar to the windows msi that allows to customize the installation
> and pick
On Mon, 15 Jun 2020 at 12:08, Christian Lohmaier
wrote:
> On Sat, May 23, 2020 at 9:32 AM Eivind Samseth wrote:
> >
> > Here’s the way you can distribute localizations on macOS
> > 1. Include all localizations in the standard download (used by all Apple
> software, MS Office etc.)
> > 2. Offer p
> As such 1 or 2 would be the preferred option if we were to design the
> system today, agree?
>
Yes.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Hello,
to take a step back:
Here’s the way you can distribute localizations on macOS
1. Include all localizations in the standard download (used by all Apple
software, MS Office etc.)
2. Offer precompiled .app bundles in the language of choice (used by Firefox)
3. Offer language packs as a separa
>
> So when you
> install help to another directory, to me it seems like a small step to
> also install install the langaugepack files to another directory
> outside the app.
>
It's not *installing* the language pack wherever we want that is the
problem. (That is just a modification to one Apple S
On Fri, May 22, 2020 at 4:03 PM Tor Lillqvist wrote:
>>
>> Selecting "good" languages is a minefield, you will surely annoy lots
>> of translators/native language speakers.
>
> And it is better to have it impossible to install language packs? OK.
Languagepacks are not impossible to install. open
Hello Tor,
I supposed you tried hard to fix this and contact every person who may help
here.
IMHO, it means we don't have the capacity to provide a localized version of
LO for MacOs correctly.
Doing an English version + all languages versions or doing 95% languages
version, etc. is just a poor ban
On Fri, 22 May 2020 at 21:05, Christian Lohmaier
wrote:
> Probably too terse. I meant solving the help issue → installing the
> help into a different directory and dealing with what you would have
> to deal with languagepacks, meaning handling the different versions of
> main LO, providing some u
Hi *,
On Thu, May 21, 2020 at 12:36 PM Tor Lillqvist wrote:
>
> A much easier solution would be for TDF to simply stop building and
> distributing language packs for macOS.
>
> Instead, my suggestion is that what should be distributed is:
>
> A build with a multitude of
>
>
>
> Selecting "good" languages is a minefield, you will surely annoy lots
> of translators/native language speakers.
>
And it is better to have it impossible to install language packs? OK.
> Both complains of "why do I have to download language xy that I never
> use/never heard of" and "why
On Thu, May 21, 2020 at 12:48 PM Eivind Samseth wrote:
>
> Sounds like a good solution, as the current method is fundamentally broken
> wrt code-signing,
Please keep problems separate. Gatekeeper validation happens way
before anything is dumped into the .app directory that can invalidate
the sig
>
>
> Cool, so if we apply file system compression to the .app bundle it will
> likely be around 1 GB on disk,
But how to do that? There is nothing in the LibreOffice Vanilla build
configuration etc that would say "enable file system compression". Maybe it
is a side-effect of it being distributed
> On 22 May 2020, at 11:45, Christian Lohmaier wrote:
>
>> So LO would still beat the 5.3 GB in total for the competition :)
>
> Yes, LO would be around 3GB...
Cool, so if we apply file system compression to the .app bundle it will likely
be around 1 GB on disk, which is only 200-300 MB more
On 22.05.2020 12:41, Adolfo Jayme Barrientos wrote:
> On 21/05/2020 12:35, Tor Lillqvist wrote:
>> * A build with a multitude of UI languages. Not all, but those with
>> "good enough" coverage. This build would also contain all
>> dictionaries (even for languages for which the UI is not i
On 21/05/2020 12:35, Tor Lillqvist wrote:
> * A build with a multitude of UI languages. Not all, but those with
> "good enough" coverage. This build would also contain all
> dictionaries (even for languages for which the UI is not included)
Let's draw that arbitrary line of coverage at..
On 22.05.20 00:32, Thorsten Behrens wrote:
> ...download extra languages dynamically,
> and then hold it - per user - in the configuration subdirectory?
This "extensions way" would be my preferred choice too. Besides the hurdles Tor
mentioned, another problem is the requirement from l10n to have
Technically, I wonder though - in case the all-in-one build would be
> deemed too bulky, couldn't we download extra languages dynamically,
> and then hold it - per user - in the configuration subdirectory?
>
>
But that is essentially the first approach I tried, where a language pack
would be instal
>
>
> The rationale for always including all dictionaries being that they are
> small enough so that it doesn't hurt?
>
>
The rationale is that what dictionaries needed by a user needs is
independent of to user interface languages used. I, for instance, would
really not want to use LibreOffice in a
On 21/05/2020 12:35, Tor Lillqvist wrote:
* A build with a multitude of UI languages. Not all, but those with
"good enough" coverage. This build would also contain all
dictionaries (even for languages for which the UI is not included)
* A number of other builds each with some geograph
Mike Kaganski wrote:
> I suggest not to do "geographic subset" builds. One build with
> everything included would be the best option - e.g., maintenance-wise
> (one single binary; no problem allowing parallel installations for the
> last remark; etc.); and also UX-wise (the additional options add
>
>
>
> I see the LO Vanilla build is 2.2 GB vs 0.8 GB for a single language build
>
One needs to also take into consideration that current macOS has a
file-level transparent compression in the file system. On my machine,
LibreOffice Vanilla.app is (as you say) 2.2 GB nominally, but (at the
moment)
Just to correct myself
LO Vanilla uses file compression so the size on disk is only 0.7 GB!
I don’t think the current TDF builds do that? Would alleviate completely any
concerns about disk space usage
FYI: Word etc. do not use compression on their .app bundle
(base) EivindsMBP2015:Applications
On 21.05.2020 13:35, Tor Lillqvist wrote:
> * A build with a multitude of UI languages. Not all, but those with
> "good enough" coverage. This build would also contain all
> dictionaries (even for languages for which the UI is not included)
> * A number of other builds each with some ge
gs that language packs install in more places than
> where it currently does. But it is quite complicated.
>
> A much easier solution would be for TDF to simply stop building and
> distributing language packs for macOS.
>
> Instead, my suggestion is that what should be
for TDF to simply stop building and
distributing language packs for macOS.
Instead, my suggestion is that what should be distributed is:
- A build with a multitude of UI languages. Not all, but those with
"good enough" coverage. This build would also contain all dictionaries
2019 03.20, Ricardo Ruff wrote:
> dear Sirs,
>
> Awaiting your comments
>
> Regards,
>
> Ricardo Ruff F.
>
>> Inicio del mensaje reenviado:
>>
>> *De: *Ricardo Ruff mailto:rr...@zayex.cl>>
>> *Asunto: **Suggestion*
>> *Fecha: *14 de m
dear Sirs,
Awaiting your comments
Regards,
Ricardo Ruff F.
> Inicio del mensaje reenviado:
>
> De: Ricardo Ruff
> Asunto: Suggestion
> Fecha: 14 de mayo de 2019, 16:00:25 CLT
> Para: libreoffice@lists.freedesktop.org
>
> Dear Sirs,
>
> I am a user of Libre Off
We handle issues and requests in our bugtracker [1]. The particular
question has been asked for in
https://bugs.documentfoundation.org/show_bug.cgi?id=37134. If you want
to learn more about the background search the web for SDI vs. MDI
(single/multi document interface).
[1] https://wiki.docum
Dear Sirs,
I am a user of Libre Office since searching in the Web a software of open
source that not depend of the big Companies that manage the world with their
closed source softwares. I congratulate you in keeping Libre Office adding
constant improvements.
As I am a user of MAC computers
Hi Andras,
Thanks a lot for your reply.
On Fri, 29 Mar 2019 13:20:27 +0100, Andras Timar wrote:
> Hi,
(snip)
> I merged your patch to master, thank you. Do not worry about translations,
> the new string will be automatically extracted by l10ntools. It's a normal
> to add new translatable strings
Hi,
On Fri, Mar 29, 2019 at 1:16 PM Takeshi Abe wrote:
> Hi,
>
> Having uploaded a patch [1] for tdf#114311 a month ago, I would like
> to ask developers who are familiar with Windows installation to check
> it. At least I have confirmed that it works on a Windows 10.
>
> It would be necessary
Hi,
Having uploaded a patch [1] for tdf#114311 a month ago, I would like
to ask developers who are familiar with Windows installation to check
it. At least I have confirmed that it works on a Windows 10.
It would be necessary to tweak the translations submodule simultaneously
to complete the fix
On 08/17/2017 11:20 AM, Michael Stahl wrote:
> by "missing words in dictionaries", do you mean that if "teh" was used
> as an archaic spelling of "tea" in a work of Shakespeare (completely
In Pinyin, the transliteration is "de".
In Wade-Giles, the transliteration is "teh".
For people who quote D
On 08/17/2017 10:08 AM, Andrej Warkentin wrote:
> So I thought this could be used to find (or at least help finding) most
> missing words in dictionaries for all languages.
Back when the OOo dictionary for Afrikaans was created, a program was
run through the dictionary corpus, excluding words th
by "missing words in dictionaries", do you mean that if "teh" was used
as an archaic spelling of "tea" in a work of Shakespeare (completely
made up and hypothetical example), that we should add "teh" to the
dictionary and no longer flag it as a wrongly spelled word?
Of course not. The result o
On 17.08.2017 12:08, Andrej Warkentin wrote:
> Hello,
>
> in a talk at the PyData Berlin meetup I saw this project:
> https://github.com/lusy/hora-de-decir-bye-bye , where spanish articles
> are scraped and searched for english words. In order to identify english
> words she used the dictionari
Hello,
in a talk at the PyData Berlin meetup I saw this project:
https://github.com/lusy/hora-de-decir-bye-bye , where spanish articles
are scraped and searched for english words. In order to identify english
words she used the dictionaries from Open Office and compared scraped
words to the d
Hi Tamas / all,
After some weeks of quiescence, and with 18 ESC types ranking these and
averaging the results (by convention we publish just the average) we
have the attached.
On 30/01/17 22:42, Zolnai Tamás wrote:
>> * TDF / Budgeting / Brainstorming (Thorsten)
>
> When will these scores
> I disagree here. In many cases I think it is wrong to simply repeat the bug
> title in the commit message of the commit that (partly or wholly) fixes the
> bug. Instead the commit message should say what the commit does. That it
> fixes a specific bug is just a side-effect, a note.
I might
> The is to describe what was the problem. For
> most bugs you cannot (should not) describe how you solved it in just one
> line.
>
I disagree here. In many cases I think it is wrong to simply repeat the bug
title in the commit message of the commit that (partly or wholly) fixes the
bug. Instead
Thanks for the suggestion, It is important that the GetInvolved page contains
what we (as a whole) want, therefore any suggestion is welcome and important.
rgds
jan i.
Sent from my iPad, please excuse any misspellings
> On 13 Feb 2016, at 13:19, jan iversen wrote:
>
> The tdf# is
The tdf# is important because it gives a reference to bugzilla, and some
automatic mechanisms use that.
The is to describe what was the problem. For most
bugs you cannot (should not) describe how you solved it in just one line.
If you look at the commit messages, most people have a rather long
Hi,
I found an issue in recommended commit message format:
tdf#12345
I had been doing so, but was recommended to describe what change has the
patch make instead in the first line because reader can see what has been
changed when collected by script.
--
Mark Hung
_
then post the patches publicly for
those who wish to integrate them.
It's no biggie. I offered my suggestion. It's out there now. I'll
incorporate it into the code and post the patch. If someone else wants to
use it for the official introduction into LibreOffice, that's fine.
Hey Rick,
On Thu, Jan 28, 2016 at 7:28 PM, Rick C. Hodgin
wrote:
> Since I haven't heard back, I'll go ahead and develop this using the
> syntax I propose. It's easily changed later.
>
> Also two more additions:
> (1) Adding a separator symbol for decimals, as in 1234.4321 being
> "1,234.432,1
Since I haven't heard back, I'll go ahead and develop this using the syntax
I propose. It's easily changed later.
Also two more additions:
(1) Adding a separator symbol for decimals, as in 1234.4321 being
"1,234.432,1"
(2) Adding a feature to Writer which allows an export of every word using
a
On Tue, Jan 26, 2016 at 5:50 AM, Eike Rathke wrote:
> Hi Rick,
>
> On Monday, 2016-01-25 16:26:53 -0500, Rick C. Hodgin wrote:
>
> > On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin >
> > > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote:
> > >> On Friday, 2016-01-08 19:52:49 -0500, Rick C. H
Hi Rick,
On Monday, 2016-01-25 16:26:53 -0500, Rick C. Hodgin wrote:
> On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin
> > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote:
> >> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
> >>
> >> > The category is called *"Metric."*
> >> >
>
On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin
wrote:
>
>
> On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote:
>
>> Hi Rick,
>>
>> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
>>
>> > The category is called *"Metric."*
>> >
>> > When conveying fractional values, such that 1.2345
On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote:
> Hi Rick,
>
> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
>
> > The category is called *"Metric."*
> >
> > When conveying fractional values, such that 1.2345E-08 (which is
> > 0.000,000,012,345), it would do so in a metric-relat
gt; > Likewise, if you're given 12.3, 1.23, and 0.123 you then MUST convert
> > SOME of them, to 12.3, 1.23, and 123e-3, OR to 0.0123e3, 0.00123e3,
> and
> > 0.123.
> >
> >
> > In this case, it would be 12.3 units, 1.23 units, 123
2.3 units, 1.23 units, 123 milliunits. The
> purpose of Metric, by default, is to auto-range the values so you are
> not looking at lengthy decimals with leading 0s, or lengthy values with
> trailing 0s before the decimal point. You get it into the appropriate
> metric range, and view it t
re not
looking at lengthy decimals with leading 0s, or lengthy values with
trailing 0s before the decimal point. You get it into the appropriate
metric range, and view it there. However, should you want to look at
everything in terms of millivolts, for example, then you can set that, and
then t
On 13/01/16 17:37, Rick C. Hodgin wrote:
> Wol, I don't understand your objection. You have seen the spreadsheet I
> created which demonstrates the various behaviors. Which one of them is
> incorrect?
Sorry, I haven't seen the spreadsheet ...
>
> The whole purpose of the Metric add-on is to aut
On 12/01/16 21:11, Rick C. Hodgin wrote:
> The values won't round.
You misunderstand me. They shouldn't round.
And based on what the user has selected, they
> will display to the nearest power of 3 (10^(k*3)), or in an explicit
> form. The default option will be to auto-range the values into th
rget! It's a home run of a concept on my scorecard.
--
Jim
-Original Message-
From: "Rick C. Hodgin"
To: libreoffice@lists.freedesktop.org
Sent: Fri, 08 Jan 2016 16:52
Subject: Suggestion
I am a developer and would be willing to make these changes for the
project, but I've ne
The values won't round. And based on what the user has selected, they will
display to the nearest power of 3 (10^(k*3)), or in an explicit form. The
default option will be to auto-range the values into their metric named
range.
Here are some examples:
http://www.libsf.org/misc/libreoffice_metric
On 12/01/2016 13:22, Rick C. Hodgin wrote:
The important part of the Metric feature is that it always wraps the
value to the nearest power of 3, and shows values in those powers.
0.1234 would be shown as 123.4 milliunits, or 1,234 microunits, for
example (however the user has set it up), and n
> The important part of the Metric feature is that it always wraps the
value to the
> nearest power of 3, and shows values in those powers. 0.1234 would be
shown
> as 123.4 milliunits, or 1,234 microunits,
Correction: should be 123,400 microunits.
Best regards,
Rick C. Hodgin
__
On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote:
> Hi Rick,
>
> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
>
> > The category is called *"Metric."*
> >
> > When conveying fractional values, such that 1.2345E-08 (which is
> > 0.000,000,012,345), it would do so in a metric-relat
Hi Chris,
On Tuesday, 2016-01-12 12:28:16 +1100, Chris Sherlock wrote:
> > All in all this sounds a bit like the idea behind the unit verification
> > that has been planned and partly been implemented in a feature branch. It
> > might be a good idea to have a look at that before implementing it
Hi Rick,
On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
> The category is called *"Metric."*
>
> When conveying fractional values, such that 1.2345E-08 (which is
> 0.000,000,012,345), it would do so in a metric-relative way using the
> standard milli (10^-3), micro (10^-6), nano (10
> On 12 Jan 2016, at 4:00 AM, Markus Mohrhard
> wrote:
>
> Hey Rick,
>
> [snip]
>
> All in all this sounds a bit like the idea behind the unit verification that
> has been planned and partly been implemented in a feature branch. It might be
> a good idea to have a look at that before implem
On Sun, Jan 10, 2016 at 01:37:17PM -0500, Rick C. Hodgin wrote:
> I've been able to setup a Linux Mint 17.1 install with build-prep, git
> clone libreoffice, compile it (whew!), run it from the command line, make
> the kdevelop projects, load module_sc into kdevelop, (...) I don't
> know if there'
Hey Rick,
On Sat, Jan 9, 2016 at 1:52 AM, Rick C. Hodgin
wrote:
> I am a developer and would be willing to make these changes for the
> project, but I've never worked on the LibreOffice code base and would need
> some help getting started with the correct source files.
>
> -
> I had an idea
Thank you, Julien! Thank you, Chris!
I've been able to setup a Linux Mint 17.1 install with build-prep, git
clone libreoffice, compile it (whew!), run it from the command line, make
the kdevelop projects, load module_sc into kdevelop, and I've located the
NumberFormatPropertyPanel.* files in modu
Hi Rick,
IMO, the *very* first step any new developer needs to undertake is to get the
LO codebase from git, compile it and then make sure it runs.
This might sound facetious to a newcomer, but actually it’s not. That is
normally the first stumbling block for any new starter (it was for me) an
Welcome Rick!
Here's the start page for those who want to contribute on dev part:
https://wiki.documentfoundation.org/Development
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Suggestion-tp4171215p4171224.html
Sent from the Dev mailing list archi
I am a developer and would be willing to make these changes for the
project, but I've never worked on the LibreOffice code base and would need
some help getting started with the correct source files.
-
I had an idea to allow for a new type of cell formatting under *"Category."*
It would be for
Hi,
Le 20/08/2014 14:35, Jay Philips a écrit :
> Hi All,
>
> Over the months of doing triaging, i've found that the best means of
> communicating with bug reporters is to have a set of pre-written
> responses to suit various common situations like confirming a bug,
> requesting a sample document,
Hi All,
Yes similar to what joel stated, i'm just posting the ones i use on the
wiki for others to use if they'd like and for those who have their own
and would like to share them, that they'd have a centralized resource to
post them to. I believe the wiki will also be a useful resource for new
QA
plate responses because we could adapt the
answer (eg: in case of LO profile if you want to give the direct link, it
depends on your env) and because indeed we don't want to be considered as
machines :-p
Julien
--
View this message in context:
http://nabble.documentfoundation.org/
Hey there,
Jay, *,
Not sure that codifying a bunch of "approved" QA exchanges is in the best
interest of moving the QA process along--especially if we have to dig them out of a WiKi.
It would not do much to improve the QA flow, nor improve the readability of issues over
their life span.
O
Hi,
On Wed, Aug 20, 2014 at 04:35:52PM +0400, Jay Philips wrote:
> So i'd like to propose the creation a wiki page of pre-written responses
> that we can all use. I have created the wiki page at <
> https://wiki.documentfoundation.org/QA/BugTriage/Pre-Written_Responses >
> and will be adding entri
Hi All,
Over the months of doing triaging, i've found that the best means of
communicating with bug reporters is to have a set of pre-written
responses to suit various common situations like confirming a bug,
requesting a sample document, and asking for clear steps. These
responses are very handy
Hi,
Test schrieb:
Hi everyone,
I hope I’m on the right place to write my suggestion / feature request.
No, it is the wrong place. This list would be suitable, if you are going
to implement the feature yourself and need some code pointers.
For discussion whether the feature is useful and
Hi everyone,
I hope I’m on the right place to write my suggestion / feature request.
There are some versions ago, MS Excel™©® had a very useful feature to manage
lists.
You started a list table by writing column labels.
In the second line, you added fonctions and formats you need for each
On 23/05/14 08:59, Richard PALO wrote:
> Le 21/05/14 10:56, Stephan Bergmann a écrit :
>> On 05/21/2014 07:13 AM, Richard PALO wrote:
>>> Either 'sdk/lib' needs to be added as a runpath-link (which works fine
>>> manually) or a symlink to libuno_sal.so.3 would need to be created in
>>> 'ure/lib' a
On 05/23/2014 08:59 AM, Richard PALO wrote:
@@ -73,7 +65,7 @@ $(eval $(call gb_Executable_use_external
))
# the orignal dmakefile said: don't ask, it's ugly
-ifeq ($(OS),SOLARIS)
+ifeq ($(OS),XSOLARIS)
$(eval $(call gb_Executable_set_ldflags,pluginapp.bin,\
-z nodefs \
))
BTW, for the
Le 21/05/14 10:56, Stephan Bergmann a écrit :
On 05/21/2014 07:13 AM, Richard PALO wrote:
S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 &&
I=$S/instdir && W=$S/workdir && g++-Wl,-z,origin
'-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program
-z nodefs $W/Cx
On 05/21/2014 07:13 AM, Richard PALO wrote:
S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 &&
I=$S/instdir && W=$S/workdir && g++-Wl,-z,origin
'-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program
-z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o
$
Hi, I'm tinkering with lo 4.2.4.2 and am having a bit of an issue
building pluginapp.bin in the extensions path, as it needs libuno_sal.so
The following is where all the flavours are found in the build tree:
$ find . -name 'libuno_sal.so*' | xargs stat -c"%N"
‘./instdir/sdk/lib/libuno_sal.so’ -
>From the QA meeting minutes:
> (*) SUGGESTION: Standardization of our summary field for Bugzilla
> (*) Or: When searching for one phrase, display results from a
< similar one (e.g. "image" -> "picture" or "graphic")
I have been thinking abou
hi.. i had applied for GSOC.. but i din get it.. 1stly i had mentioned a
conflict with my exams.. 2ndly, while writing my proposal, i wasn't too
clear about the project(though i would like to explore a lot in that
area).. 3rdly, my patch: first one was abandoned since there was already a
similar on
1 - 100 of 182 matches
Mail list logo
