Solaris, of course, is doing something else quite different, though. They are trying to make the transition from a proprietary customer/supplier relationship to trying to develop an Open Source community (..) We don’t have a lot of precedent for projects who try to go in this direction, but I suspect they are skipping a step when they try to go to the end step without bothering to try to make themselves open to outside developers. And by continuing to act like a corporation, they end up shooting themselves in the foot.A nice wording of the sentiment in the FLOSS community. I have been wondering for quite some time now how it is possible that even small projects like LilyPond and GRUB 2 seem to have a much more lively user and developer community than OpenOffice.org has. Is office software so much more unsexy than music notation or bootloading? Is OpenOffice.org so much more bug-free that users/developers don't need to get involved? Are we as developers not taking enough pride in our work? Is OpenOffice still too young? Is there not enough competition, too little eyeballs? Are we hurt by artificial (corporate) agenda's or a cultures that prevent writing of beautiful code? So how is this transition from being a corporate project which happens to publish most source code to a true organic open source project supposed to happen? How can we speed this process up, or even prevent it from being slowed down? Should we seek to divide and make work of our Go-OO.org community: we fix getting your patches in and deliver a buildable tree? It is doubtfult if that is what would serve OpenOffice best. But what can we do? What are people at Sun thinking, are they seeing what we are seeing? Is there any guidance in this or is there too much guidance, are there expectations or dreams, is there a plan?
#348669 - zypper should print progress to stderr #348676 - zypper should list package descriptions/summaries
Poke at both implementations for a few hours and finally
find that the [re]draw and detachment problems arise from
the silly fact that at time of creation the DialControl
Plugin's parent is 0. Apparently this does unfixable
damage, at least not fixable by reparenting later. Anyway,
the dialog now looks and moves fine.
Visit Ei/PSI
grand opening. Inspiring and sobering talks by Whitfield
Diffie, Andrew Odlyzko, Ian Brown and Bruce Schneier. It is
amazing to watch the vastness of the domain that people like
Andrew and especially Bruce can choose to talk about, what
stretches they make and how they just get away with it. No,
that's not it. Great speakers understand the art of how
talking about big and profoundly simple things, that could
others easily cost their credibility and respect, makes them
bigger.
Set out to make fresh pasta today. A couple of years ago I
tried it for the first time, inspired by a lovely meal that
Han-Wen prepared for us. It was a mixed succes then, some
bits were really too thick. This time it went very well
though. I learned again that big eggs are much bigger here
than
Marcella Harzan buys them in Italy. Although I tried to
use the original method of stretching and flattening the
pasta for a bit, in the end I used a common Dutch rolling
pin and got a nice evenly thin sheet of pasta.
Get plugged-in svx:DialControl to hello world through
UnoTunnel. When the dialog pops up, the size is already
right! The contents of my editor window show up as background,
but no complaints for a first result.
And it gets even better, clicking on the expected location
shows a functioning DialControl. Woo!
It doesn't get much better, though. Altough the DialControl
is reparented using the ModalDialog from the UnoTunnel, they
somehow act as separate windows. Spend rest of day poking
these separate/unattached window, background and redraw
issues.
"missing vcl resource"and images are broken. Rush to checkout and download ooh-m12 before dinner, that should work.
Make VBox, HBox vcl wrappers usable. Test with recover.cxx,
but revert to using individual visibility instead because of
spacing/sizing problem. Running the recovery dialog from
DEV300-m2 has a pleasant surprise: the progress bar has been
updated to use a more modern GNOME-like one.
Find that FixedLine and zoom.cxx have been extended
upstream. Implement FixedLine.IsEnabled () and add new View
Layout functionality to zoom.xml; merge and create minimal
diff for zoom.hxx, zoom.cxx.
After running the upstream
dialog, I realise that Zoom factor and View layout parts
are in columns, alongside each other.
After adding an extra vbox and hbox this is what the new
layout-based zoom dialog looks like. Now I need to redance
the whole translation hoopla for the new strings.
Add Simple/Advanced mode to recovery dialog. I loosely
based it on
the design made by Sigi in bug
#194434.
Only loosely, because I'm not sure how to do the floating
box with documents. But also because I am no particular fan
of the hidden right-click functionality anyway, which then
has to be documented and is also bothering the casual user.
Do we also need to display the recovery status with each
document?
How is that for helpful? Time for another bug report :-)<!-- DT:Rich --> <p>GNU LilyPond is a music typesetter. </p>
sunstudio12.../ld: unable to find version dependency `UDK_3.0' sunstudio12.../ld: unable to find version dependency `SALHLP_1_0' sunstudio12.../ld: anonymous version tag cannot be combined with other version tags
Do obvious thing for CancelButton, fail.
Try less obvious things.
Redo obvious CancelButton thing. Look. Notice
silent failure of VCLXButton::setLabel, setProperty.
while running standalone TEST application from CWS. For the rest it works fine, except background is dark gray."Missing vcl resource. This indicates that files vital to localization are missing. " "You might have a corrupt installation."
Return from my Avatar® training. Wow.
Thirteen days. The day starts with Tai chi. After breakfast a inspiring talk from Harry and then on to your morning program: simple but awesome and mindbogglingly clever experiential exercises that eventually trick your mind into giving up information that is transparent to you. Such information may be quite confronting--which is why the mind tries so hard to keep it secret--but very helpful once discovered.
The rest of the day is filled with intriguing exercises that let you expecience new aspects of shifting viewpoints, attention, desire/resistance, identity, etc. Some lead to profound insights or disclose repeating patterns in your life. Others help you lay out the blueprint of your mind and change it. Or shift your mode of conciousness, or make you experience unbelievable connection with and compassion for others.
A truely fantastic journey in conciousness, an empowering, humbling, mind broadening and joyful experience.
Realize that as an example language, German might be a
better choice than Dutch, so add German translations too.
Interestingly, the default buttons do not translate [to
German]. Probably that's a local build problem as default
buttons in old style dialogs are also in English. Leave
this (as well as the simple teaser bug :-) to the fresh
rebuild after
my inspiring vacation.
Look into read-right translation of images. After a few
fruitless attempts to reuse that code to read layout xml
files, add another simplistic implementation to layout.
Ugh. To get things going, also add manual translations of
the zoom and wordcount dialogs and intergrate it all into
OOo.
It seems as if some macros are expanded twice, or that #undef does not work. Or quite possibly someone is trying to be smart, as we include layout-pre.hxx twice. We may have to remove the multiple inclusion shielding from that file and add another set of include headers layout-pre-header.hxx and layout-pre-source.hxx which simply include layout-pre.hxx again.( ( layout :: layout :: RadioButton * ) pCaller ) ; } long SvxZoomDialog :: UserHdl ( layout :: RadioButton * pBtn )
Jakub has made a two beautiful sets of buttons. Now add
them to the layout code.
Too bad that the OOo toolbar also has an help button image
with a life buoy.
aOptimalBtn.SetText( String( SVX_RESSTR ( RID_SVX_ZOOM_OPTIMAL ) ) ); aPageWidthBtn.SetText( String( SVX_RESSTR ( RID_SVX_ZOOM_PAGEWIDTH ) ) ); aWholePageBtn.SetText( String( SVX_RESSTR ( RID_SVX_ZOOM_WHOLEPAGE ) ) );
Duh. To be fair, this code should not have been there. I
only debugged as far as initializing all buttons. After
removing these lines this is what native OOo zoom box looks
like. The texts that were translated are now missing.
These prove to be introduced by
the zoom-combobox.diff patch, which also removes
them from the zoom.src file.
Great. The rebuild fixed most localization issues, I now
have a fully localized Dutch and German (en-US, nl, de)
install. The cancel-button is translated (nl=Annuleren).
The zoom dialog however has still three untranslated
strings. The wordcount dialog is not translated at all.
Oddly, they are exactly the strings that I added in
my jcn.sdf. Now, do these still not translate, or did I
break it? Not good.
svx source\dialog\zoom.src 0 radiobutton RID_SVXDLG_ZOOM\ BTN_USER 42 en-US ~Variable svx source\dialog\zoom.src 0 radiobutton RID_SVXDLG_ZOOM\ BTN_USER 42 nl ~Variabelle svx source\dialog\zoom.src 0 fixedline RID_SVXDLG_ZOOM\ FL_ZOOM 92 en-US Zoom factor svx source\dialog\zoom.src 0 fixedline RID_SVXDLG_ZOOM\ FL_ZOOM 92 nl Zoomfaktor svx source\dialog\zoom.src 0 modaldialog RID_SVXDLG_ZOOM\ SID_ATTR_ZOOM 160 en-US Zoom svx source\dialog\zoom.src 0 modaldialog RID_SVXDLG_ZOOM\ SID_ATTR_ZOOM 160 nl Schaal
Finally a partial localization success: some strings of zoom
are translated. It turns out that these translations happen
live in some other dialog's
definition: stbctrls.src. Not translated: title
(nl=Zet zoomfactor), fixed-line: (nl=Zoomfactor), radiobutton
(nl=Variabel), cancel-button (nl=Annuleren). Adding
hardcoded translations to zoom.src or merging my
own jcn.sdf hack does not
help.
It helps if you know that the full name for libgtksourceview-2_0-0-2.0.0-5 is libgtksourceview-2_0-0.sed -e 's/-[^-]\+-[^-]\+$//'
one is tempted to think that something likelilypond-2.10.29-24
might work, like in Cygwin. Considersed -e 's/-[0-9][0-9.a-f]\+-[0-9]\+//'
I gave up anyway. I found a way out, instead of rpm -qai I now use rpm-get-selections.SuSEfirewall2-3.6_SVNr183-10 gpg-pubkey-1abd1afb-450ef738 hal-32bit-0.5.9_git20070831-13 cdparanoia-IIIalpha9.8-626 iso-codes-1.0a-49 libgtksourceview-2_0-0-2.0.0-5 libopenssl0_9_8-32bit-0.9.8e-45.5
grep "rpm' '-e'" /var/log/zypper.log | tr -d "'" | sed 's/.* //' > removed
too. As an example, add an xml mockup of
openSUSE's 10.3 shut- down applet dialog, which has a quite a
nice number of extra buttons, again formatted for the
various platform options.
More standard buttons for <dialog- buttonhbox>:
Yes, No, Retry,
Ignore, Reset, Apply.
Implement <dialogbuttonhbox>. As an example, add dialogbuttons.xml.
Also use it in the wordcount
and zoom dialogs. This already looks
a whole lot better. Now for the proper icons...
and vote for some others. That should help get us up to speed as development platform :-)#348669 - zypper should print progress to stderr #348676 - zypper should list package descriptions/summaries #348683 - Zypper [info] is amazingly slow #348685 - zypper should list or install build dependencies for package #348733 - zypper should have --download-only and --cache options #348738 - xorg.conf is unclear about editing, regenerating/overwriting, inserting [openchrome] driver #348741 - metacity's maximize-vertically makes windows too tall
does not make the dialog un-modal. Also, our Dialog::setParent () is empty. Will look into SetParent on Monday.// SfxModalDialog( pParent, SVX_RES( RID_SVXDLG_ZOOM ) ), SfxModalDialog( 0, SVX_RES( RID_SVXDLG_ZOOM ) ),
#if 0 mpMediaWindow->SetForwardKey( TRUE ); #endif
some heavy caching going on.../etc/sysconfig/displaymanager:DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" /etc/gdm/gdm_sysconfig.conf:DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" /etc/gdm/custom.conf:DisallowTCP=false
so it seems there is a problem with the biosinfo: disabling this check makes the driver for my P4M890 work.(II) VIA(0): URG Accepting: CrtHDisplay (1680) * CrtVDisplay (1050) * VRefresh (59) * bitsPerPixel >> 3 (32, 4) = 423037184 > 74000000 (biosinfo: BandWidth)
but also found that default build [on SUSE now] is without -g?(gdb) bt #0 0x00002b016bcdfcc9 in ?? () from ./libvcl680lx.so #1 0x00002b016bce5d2d in MetricFormatter::Reformat () from ./libvcl680lx.so #2 0x00002b016bce5e39 in MetricBox::ReformatAll () from ./libvcl680lx.so #3 0x00002b016c4d2b60 in ?? () from ./libsvt680lx.so
#347624 - yum installs i586 packages on x86_64 which easily results in serious breakage
:-)Build succeeded ...! touch stamp/build
Here is what OOo currently does on GNOME. If you are used
to GNOME it feels a bit funny.
That is because
our hig
guidelines say that alert buttons should look like this.
Here are the buttons of a typical GNOME save alert.
should then produce a native ordering for different platforms.<alerthbox> <okbutton id="BTN_ZOOM_OK" default="true"/> <cancelbutton id="BTN_ZOOM_CANCEL"/> <helpbutton id="BTN_ZOOM_HELP"/> </alerthbox>
the localisation marker will probably be different.<okbutton id="BTN_SAVE_OK" default="true"/> label="_(~Save changes)">
On Windows XP, the default OK/Yes and Cancel/No texts can be
used if that is what XP users expect (Ja=Yes, Nee=No,
Annuleren=Cancel in Dutch). How do I run LANG=
msword.exe?
The build was ready, so I can test the zoom dialog. It
starts fine, but where do these retro icons come from? I
decide to remove debug printing from the layout code as most
of it is tracing. I notice that the code could also do with
some whitespace cleanups before it goes into ooo-build, so I
script some to fix the worst offenders. There are also lots
of unnecessary includes and remove two catch-all globals.hxx
headers, prune most of them. There, ready to make my first
commit to ooo-build!
and everything should be fine (patch.apply and patch.unapply fail sometimes and rebase may find a conflict, of course). But I can't do that because my patches live on top of ooo-build's patches, so I just have to hope for the best. If something goes wrong, there's always rm -rf and git format-patch, git am :-)git branch -f svn-up patch.apply git checkout svn-up make patch.unapply svn update # or, git-svn rebase :-)) make patch.apply git commit -a -m 'Svn update.' git checkout master git rebase svn-up
The GIT juggling and re-builds leave me a lot of time to
hack on Kohei's src2xml converter. I add the postprocessing
and then some, so that the zoom dialog runs straight from
the converter. It turns out that the hbox and vboxes are
not specified in the original .SRC, so it seems
we'll really want to massage the xml manually.
Spent most of my day preparing [LayoutDialog] patches to go
into ooo-build. There's one interesting thing to show
today, I put the OK and Help buttons of the wordcount dialog
inside an
<hbox homogenous="true">. Eventually we will
need a special hbox that is platform-aware for Cancel/Help/OK
buttons, that will automagically order the buttons according
to the platform's rune.
Now that's more like it.index caeddf2..b801ada 100644 --- a/sw/source/ui/dialog/wordcountdialog.cxx +++ b/sw/source/ui/dialog/wordcountdialog.cxx @@ -50,6 +50,7 @@ #endif #include <dialog.hrc> +#include <layout/layout-pre.hxx> #include <wordcountdialog.hrc> /*-- 06.04.2004 16:05:55---------------------------------------------------index 2030487..1c96157 100644 --- a/sw/source/ui/inc/wordcountdialog.hxx +++ b/sw/source/ui/inc/wordcountdialog.hxx @@ -43,6 +43,8 @@ #ifndef _SV_BUTTON_HXX #include <vcl/button.hxx> #endif +#include <layout/layout.hxx> +#include <layout/layout-pre.hxx> struct SwDocStat; class SwWordCountDialog : public SfxModalDialog { @@ -70,4 +72,6 @@ public: void SetValues(const SwDocStat& rCurrent, const SwDocStat& rDoc); }; +#include <layout/layout-post.hxx> + #endif
and keep kicking it?undefined reference to `std::allocator<char>::allocator(std::allocator<char> const&)' undefined reference to `std::allocator<char>::~allocator()' hidden symbol `std::allocator<char>::allocator()' isn't defined
Start the day with a fun task: getting the percent (%) sign
to work in the zoom dialog. I decide to just go looking in
the implementation of MetricField. This tells me that the
Custom Unit property is not set. I knew this, it is
commented-out in the zoom.xml file because it does not work.
Enabling it shows that we do not grok properties of
enumerated type, such as Custom Unit. Interestingly, enums
are 16bit in Uno. Anyway, an easy task with a nice result.
Inspired by the word count dialog tweaks, add a couple of
tweaks for the zoom dialog too. Wider borders, add some
space between the `Variable' label and spin button box. An
experimental addition is an extra indentation for the list
of radio buttons, but this hack adds another pair of hbox
and vbox, which makes for ugly resizing.
On to porting a new dialog today: the word count dialog.
That does not seem too difficult, right? Also, I `discover'
Kohei's converter which generates the first default layout,
almost ready to use.
As it is a bit tight, I add some spacing. Now get the code
ready and plug it into OOo.
But wait, the zeroes are not really aligned, are they. The
top zero is a few pixels to the right. When the dialog is
widened, the upper zero `jumps' to the left but now it is a
few pixels too far to the left. Funny bug.
I have a look into the %-sign that is not displayed in our
zoom box. Not sure how this works. Adding FUNIT_PERCENT
does not fix it. We do set a property
custom-unit-text=" %". Hmm. Other than that and
the new crash that I found today, the new zoom dialog looks
perfect! Just to remind you I've put up a picture of the
classic OOo zoom dialog below. Now how does it do that
percent (%) sign? ;-)
Hunted down the extra pixel in the Variable radiobutton's
left margin. This fixes all known visual bugs in the zoom
dialog! Added Help and OK interface similar to Cancel.
to my ~/.emacs.el which makes C-x C-f behave in the way you would expect.(require 'ffap) (ffap-bindings)
Off to fix the Variable radiobutton's behaviour but found
that the Variable user radiobutton actually activates the
metric field. This may well have been related to the vtable
problem resulting in the disfunctional OK button. Well well,
if bugs go fix themselves as quickly as this :-))
Found new visual bug rightaway though: see what happens if
the metric field value is increased to 10. You can just see
the edge of the 10's zero at the right. So, the metric
field is too narrow by default, or allows too big values,
and/or does not resize (correctly) when the contents get
bigger. Leaving that for now.
Couple of small tweaks to zoom.xml. Almost there. The ugly
margin is gone and is not expanded any more when the dialog
is stretched, but we are still losing one pixel somewhere.
Fix width of SpinField button. It's especially noticable at
bigger font sizes that the width of the spinfield button is
not calculated correctly. It turns-out not to be really
calculated at all :-)
Another small but nice improvement: consider text height of
a FixedLine that has text.
Michael's off for a week but he left a very nice and soft
introduction into the layout code in the form of a TODO
list. The zoom dialog is a layout'ified copy of a real
dialog in OpenOffice and apart from the odd little icon
buttons it doesn't really seem to look so bad...
...until you resize the dialog and find what's missing...
At the top there's a Zoom Factor----- widget getting
squashed and the OK, Cancel and Help buttons have labels
that are apparently ignored while calculating their width.
Aah, much nicer, isn't it? Now the text label of the
buttons is actually taken into account when calculating the
size of the button. Fixed [my] first bug: button sizing.
In: http://lilypond.org/~janneke/vc/ooo 6b55a198..9cb76668.