Re: [Libreoffice] Are we back to having this spec process again!?
Hi Kohei, Am 09.07.2011 19:39, schrieb Kohei Yoshida: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I'd rather say he started to collect information in a structured way to help all the people involved in a new feature implementation. And to make more people aware that their help is needed. I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? It's not about a mandatory over-engineered process. I started something similar for the gridline display. I (and others) found this quit helpfull - but I would not do it again in that detail for quite simple patches. It was more to see, what might work and what not. Anyway - what I really dislike from your further communication (your answer to Christoph) is the way you speak about us developers and you UX, QA and documentation guys. It's after all we who create and develop LibreOffice. All that said: if you can suggest some other word for spec I'd be quite happy. For me it is more or less a notes collection for an implementation - and not the thing that was used at OOo. What Rainer and me currently do with those spects is really only a first step and maybe a step to far. Again - we are currently trying to see what works and what not. André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Better support for distro packaging
08 Temmuz 2011 Cuma günü (saat 17:00:48) Petr Mladek şunları yazmıştı:
Hi,
are you fine with adding the attached changes into master and
libreoffice-3-4 branch?
These changes help me to create SUSE packages. Most of the stuff comes
from the build repo and should be useful for other packagers as well.
The changes should be pretty safe. Most scripts are called only with the
new target make distro-pack-install. In addition, it adds few more
configure switches and environment variables. See the commit messages
for more details.
Note that I did not migrated all features from the build repo. I wanted
to do some clean up during this more, ... We could add them later is
really needed.
I tested it only with vendor Novell, inc. I am sure that there will be
problems with other vendors. IMHO, it should not cause harm because it
affects only few interested package maintainers. They should be able to
fix problems and send patches.
In the first patch named -L.patch, an absolute-path symlink is created
using:
for dir in `find $lo_src_dir/$tarname -mindepth 1 -maxdepth 1 -type d` ; do
ln -sf $dir $start_dir
and this is not good since I prepare one giant libreoffice tarball in a
temporary directory of a different machine, which means the system that I
download the sources and the system building sources is different. So that
abosolute path symlink seems broken in the a different machine.
What about making it a relative symlink instead using something like:
ln -sf ${dir/$start_dir\/} $start_dir
or
ln -sf `echo $dir | sed -e s,$start_dir\/,,` $start_dir
Best Regards,
Petr
--
Gökçen Eraslan
signature.asc
Description: This is a digitally signed message part.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Are we back to having this spec process again!?
How about design notes. Sometime it is important to have an explicit statement on essential characteristics and the function being served. I would hope it is generally apparent when such consideration is important to have. - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of André Schnabel Sent: Sunday, July 10, 2011 02:58 To: libreoffice@lists.freedesktop.org Subject: Re: [Libreoffice] Are we back to having this spec process again!? Hi Kohei, Am 09.07.2011 19:39, schrieb Kohei Yoshida: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I'd rather say he started to collect information in a structured way to help all the people involved in a new feature implementation. And to make more people aware that their help is needed. I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? It's not about a mandatory over-engineered process. I started something similar for the gridline display. I (and others) found this quit helpfull - but I would not do it again in that detail for quite simple patches. It was more to see, what might work and what not. Anyway - what I really dislike from your further communication (your answer to Christoph) is the way you speak about us developers and you UX, QA and documentation guys. It's after all we who create and develop LibreOffice. All that said: if you can suggest some other word for spec I'd be quite happy. For me it is more or less a notes collection for an implementation - and not the thing that was used at OOo. What Rainer and me currently do with those spects is really only a first step and maybe a step to far. Again - we are currently trying to see what works and what not. André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] Missing localizations of Presenter screen
Hi, Localizations of Presenter screem extension were made but not built in into the final deliverable. This bug was reported last Thursday on l10n list, however, it is not a new one. It is present in all releases of LibreOffice. I don't know how the authors of the makefile wanted to handle localizations. It seems they started something (see the lines with FIND_XCU) but it was not finished. The other extension in this module (Presentation minimizer) uses a different makefile template which is correct. I did not have the time to fully decipher the makefile of Presenter screen, so I added an ugly hack only which makes sure that localizations are included. I hope this is acceptable for LibreOffice 3.4.2. http://cgit.freedesktop.org/libreoffice/extensions/commit/?id=2fdd60dc1782048cefc748f18ea4eed1464f6333 Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Making default tab prefix name configurable in Calc
Hi Kohei,
Thanks for your comments.
On Fri, Jul 8, 2011 at 05:02, Kohei Yoshida kyosh...@novell.com wrote:
On Sat, 2011-07-02 at 12:09 +0200, Albert Thuswaldner wrote:
Hi
Submitting a patch for review. This one enables the user to set the
default tab prefix name in calc.
The new option is located in Menu - Tools - Options - LibreOffice
Calc - Defaults
- I think this Is a useful feature for some at least, a few LO/OOo
users i've talked to seem to agree.
- it is unobtrusive to the user, it does not change the default behavior.
- also code-wise it does not come with any radical changes.
As always please let me know if you want me to improve it.
Hi Albert,
First of all, thanks for your patches. It's good to see you continue to
work on hacking Calc. As you requested, here are my comments on your
changes followed by the relevant (partial) hunk.
1)
+ SC_DLLPUBLIC sal_Bool GetFallBackPrefix(String aStrPrefix)
const;
Let's use the real bool here instead of sal_Bool in the new method
signature. Also, let's use rtl::OUString instead of String here as
well. We are trying very hard to remove sal_Bool and String types, so
it's best not to use them in new code.
Ok I'll fix that. I actually though that sal_Bool was the preferred
type, now I know better.
2)
+ // Test if prefix is valid
+ sal_Bool bPrefix = ValidTabName( aStrPrefix );
+ if ( !bPrefix )
+ {
+ bPrefix = ValidTabName( aStrPrefix );
+ aStrPrefix = aStrPrefix2;
+ }
Our preferred bracket style would be
+ if ( !bPrefix )
+ {
+ bPrefix = ValidTabName( aStrPrefix );
+ aStrPrefix = aStrPrefix2;
+ }
typo, fixing it.
3)
+ case SCDEFAULTSOPT_TAB_PREFIX:
+ OUString aPrefix;
+ if (pValues[nProp] = aPrefix)
+ SetInitTabPrefix(aPrefix);
+ break;
+
Here, you've declared a local variable inside a case scope. You need to
surround the whole case block with { } like so:
case SCDEFAULTSOPT_TAB_PREFIX:
{
...
}
Ok, do that.
4)
@@ -84,4 +92,6 @@ int ScTpDefaultsOptions::DeactivatePage(SfxItemSet*
/*pSet*/)
return KEEP_PAGE;
}
+//ScGlobal::GetRscString(STR_TABLE_DEF); //Table
+
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
This hunk is unnecessary.
Yea, left over should have been deleted.
5) Regarding the options paths, with your change we now have
Calc/Defaults/Other/TabCount
Calc/Defaults/Other/TabPrefix
option paths. I would prefer changing them to
Calc/Defaults/Sheet/SheetCount
Calc/Defaults/Sheet/SheetPrefix
because 1) I don't like to use Other or Misc *unless* there are no other
options, and 2) these options apply globally to sheet's internal default
behavior, not just the sheet tab, so I would prefer that being reflected
in the option names as well. Here, whether to use Sheet or Table is a
matter of preference, but I tend to use Sheet in user visible parts.
Ok, makes perfectly sense now that there are two options in this
category. I'll make the change.
These are minor issues, and I can make these changes if you want me to.
Thanks but I'll do that myself, otherwise I will never learn. ;)
Now, a slightly bigger issue. The sheet prefix option input box doesn't
check for valid sheet name. It even allows an empty one, which is not
very good. So, we should at least apply the same restriction as in
ScDocument::ValidTabName() method (located in document.cxx#250). You
can simply call that method from the option page to validate the name
since that method is static.
The preferred way to set the restriction is to inspect the new name each
time the text value in the input box changes. You can intercept a input
value change event for the input box to do the inspection and accept or
reject the new text value. I believe there are other UI parts that do
the same thing so hopefully you can find some example code to follow.
If not, let me know and I'll dig in to find one.
This is all I can think of at the moment. Let me know if you need more
clarifications on any of these points.
It makes sense to check it directly at input. I wasn't sure how to
implement that, especially without cluttering up the code.
Thanks for the pointers. i will have a go at it.
/Albert
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Better support for distro packaging
On Fri, Jul 08, 2011 at 07:27:37PM +0200, Andreas Radke a.ra...@arcor.de wrote: The former man-page is still missing. Did you read Petr's patch? bin/distro-install-desktop-integration takes care of that now. pgp2NwSIXikH2.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Better support for distro packaging
Am Sun, 10 Jul 2011 21:10:37 +0200 schrieb Miklos Vajna vmik...@frugalware.org: On Fri, Jul 08, 2011 at 07:27:37PM +0200, Andreas Radke a.ra...@arcor.de wrote: The former man-page is still missing. Did you read Petr's patch? bin/distro-install-desktop-integration takes care of that now. Yeah, but why do we need that distro install target at all? A fully working simple make install we had in old ooo-build days should satisfy everyone not only distro packager. -Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Internal cairo and Postscript and PDF surface
Just wondering whether we need the postscript and pdf surfaces in our internal cairo build. The configury is not able to find the dependencies and bails out there because they are now recommended surfaces. Adding manually --disable-ps --disable-pdf makes the build go over it. Just wondering whether I should look for other solution, or are the two disable statements enough? F. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC][patch] Multiline inputbar
Hello Kohei,
As said I've modified the codebase over Noel's patch and worked on
showing the button up and basic toggling working. So far the text
window and the container class resizes well base on the button click.
But currently I'd need to work on following things also
1: Setting the proper output area when the toggling happens. I've
tried working on it but was not able to get vertical offset proper
when in multiline mode. So need to look more into its mathematics.
2: As Noel mentioned in, his last mail that I'm setting the height to
TBX_WINDOW_HEIGHT instead it can be more than that. I tried fetching
the current height in ScMultiTextWnd::Resize() and setting the correct
height but I did some wrong implementation and LO was crashing because
of that. So I'd need to look into that too.
3: The third thing is, when the resize happens, the ScInputWindow i.e
toolbox doesn't resize. The overflow of the child window is hidden
inside ScInputWindow.
So this patch contains a basic button implementations and toggling of
the textbox (resizing it) based on the click. I took time because it
took some time to understand the new codebase which makes this feature
runtime switchable. Please review it as soon as possible and help me
work on the above mentioned things.
Thanks and regards
--
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index 2d7a748..1fb7c6b 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -51,6 +51,7 @@
#include vcl/cursor.hxx
#include vcl/help.hxx
#include svl/stritem.hxx
+#include stdio.h
#include inputwin.hxx
#include scmod.hxx
@@ -81,6 +82,7 @@
#define TEXT_MULTI_STARTPOS 5
#define THESIZE100 //!!! langt... :-)
#define TBX_WINDOW_HEIGHT 22 // in Pixeln - fuer alle Systeme gleich?
+#define LEFT_OFFSET 5
enum ScNameInputType
{
@@ -176,7 +178,7 @@ ScInputWindow::ScInputWindow( Window* pParent, SfxBindings* pBind ) :
}
DBG_ASSERT( pViewSh, no view shell for input window );
-// Positionsfenster, 3 Buttons, Eingabefenster
+// Position window, 3 buttons, input window
InsertWindow( 1, aWndPos, 0, 0 );
InsertSeparator ( 1 );
InsertItem ( SID_INPUT_FUNCTION, IMAGE( SID_INPUT_FUNCTION ), 0, 2 );
@@ -187,9 +189,12 @@ ScInputWindow::ScInputWindow( Window* pParent, SfxBindings* pBind ) :
aWndPos .SetQuickHelpText( ScResId( SCSTR_QHELP_POSWND ) );
aWndPos.SetHelpId ( HID_INSWIN_POS );
-aTextWindow.SetQuickHelpText( ScResId( SCSTR_QHELP_INPUTWND ) );
-aTextWindow.SetHelpId ( HID_INSWIN_INPUT );
-
+
+if ( !lcl_isExperimentalMode() )
+{
+aTextWindow.SetQuickHelpText( ScResId( SCSTR_QHELP_INPUTWND ) );
+aTextWindow.SetHelpId ( HID_INSWIN_INPUT );
+}
// kein SetHelpText, die Hilfetexte kommen aus der Hilfe
SetItemText ( SID_INPUT_FUNCTION, ScResId( SCSTR_QHELP_BTNCALC ) );
@@ -477,7 +482,7 @@ void ScInputWindow::Select()
aTextWindow.StartEditEngine();
if ( pScMod-IsEditMode() ) // nicht, wenn z.B. geschuetzt
{
-aTextWindow.GrabFocus();
+aTextWindow.StartEditEngine();
aTextWindow.SetTextString( '=' );
EditView* pView = aTextWindow.GetEditView();
@@ -497,20 +502,24 @@ void ScInputWindow::Select()
void ScInputWindow::Resize()
{
ToolBox::Resize();
-
-long nWidth = GetSizePixel().Width();
-long nLeft = aTextWindow.GetPosPixel().X();
-Size aSize = aTextWindow.GetSizePixel();
-
-aSize.Width() = Max( ((long)(nWidth - nLeft - 5)), (long)0 );
+
if ( lcl_isExperimentalMode() )
{
-aSize.Height()= TBX_WINDOW_HEIGHT;
-aTextWindow.SetSizePixel( aSize );
+//aSize.Height()= TBX_WINDOW_HEIGHT;
+//aTextWindow.SetSizePixel( aSize );
aTextWindow.Resize();
}
-aTextWindow.SetSizePixel( aSize );
-aTextWindow.Invalidate();
+else
+{
+long nWidth = GetSizePixel().Width();
+long nLeft = aTextWindow.GetPosPixel().X();
+Size aSize = aTextWindow.GetSizePixel();
+
+aSize.Width() = Max( ((long)(nWidth - nLeft - 5)), (long)0 );
+
+aTextWindow.SetSizePixel( aSize );
+aTextWindow.Invalidate();
+}
}
void ScInputWindow::SetFuncString( const String rString, sal_Bool bDoEdit )
@@ -518,8 +527,10 @@ void ScInputWindow::SetFuncString( const String rString, sal_Bool bDoEdit )
//! new method at ScModule to query if function autopilot is open
SfxViewFrame* pViewFrm = SfxViewFrame::Current();
EnableButtons( pViewFrm !pViewFrm-GetChildWindow( SID_OPENDLG_FUNCTION ) );
-aTextWindow.StartEditEngine();
-
+if ( !lcl_isExperimentalMode() )
+aTextWindow.StartEditEngine();
+else
+aTextWindow.StartEditEngine();
ScModule* pScMod = SC_MOD();
