> Regarding version information, there is solver/*/inc/*minor.mk
And of course the very file name of that "*minor.mk" contains the
mysterious three-digits-no-separators number which is a relic from
conventions in the OOo EIS/MWS/CWS days;)
> (make-level
> variables VERSIONMAJOR, VERSIONMINOR, etc
Hi,
On Wed, Jan 9, 2013 at 4:51 PM, Michael Meeks wrote:
> Hi Ruslan,
>
> On Sat, 2013-01-05 at 22:59 +0300, Ruslan Kabatsayev wrote:
>> What about such a simple change, which will let us set LibO version
>> once and for all GTK theme calls:
>
> I guess we could do; we'd want to produce a
On Wed, 2013-01-09 at 15:47 +0100, Stephan Bergmann wrote:
> Regarding version information, there is solver/*/inc/*minor.mk
> (make-level variables VERSIONMAJOR, VERSIONMINOR, etc.) and there is
> solenv/inc/version.hrc including versionlist.hrc (#defines for VERSION,
> SUBVERSION, etc.).
On 01/09/2013 02:54 PM, Michael Meeks wrote:
Why not just use some more normal, verbose and explicitly named macros
like LIBO_MAJOR_VERSION, LIBO_MINOR_VERSION, LIBO_MICRO_VERSION,
LIBO_PATCHLEVEL, or something similar?
Go for it - it sounds like the libo-version thing is not currently
Hi Tor,
On Wed, 2013-01-09 at 15:06 +0200, Tor Lillqvist wrote:
> Hmm, I have wanted us to eventually get rid of this mysterious "SUPD"
> symbol, and SOURCEVERSION == WORK_STAMP, who have their historical
> roots in the MWS names of the old Sun OOo, and thus are meaningless to
> us.
:-)
> Using SUPD is reasonably easy - it is a 4.0.0 -> 400 thing: not
> terribly robust over big versions, but easy enough to parse I guess.
Hmm, I have wanted us to eventually get rid of this mysterious "SUPD"
symbol, and SOURCEVERSION == WORK_STAMP, who have their historical
roots in the MWS
Hi Ruslan,
On Sat, 2013-01-05 at 22:59 +0300, Ruslan Kabatsayev wrote:
> What about such a simple change, which will let us set LibO version
> once and for all GTK theme calls:
I guess we could do; we'd want to produce a real version string for a
patch though :-)
The reason why I
Hi Michael,
What about such a simple change, which will let us set LibO version
once and for all GTK theme calls:
---
diff --git a/vcl/unx/gtk/app/gtkdata.cxx b/vcl/unx/gtk/app/gtkdata.cxx
index 14a1949..ec11a8f 100644
--- a/vcl/unx/gtk/app/gtkdata.cxx
+++ b/vcl/unx/gtk
On Wed, 2012-11-21 at 19:46 +0400, Ruslan Kabatsayev wrote:
> This doesn't seem to be a very easy thing. Oxygen-gtk gets application
> name via g_get_prgname() and also from PID reading /proc/$PID/cmdline.
> Not very extensible for versions.
Right :-)
> Yeah, g_object_set_data with LibO
Hi,
On Wed, Nov 21, 2012 at 6:36 PM, Ivan Timofeev wrote:
> Hi,
>
> So, background gradients are fixed now with
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0a5eed63b871e2febb36e27e9dea4b7e57f681b
Thanks, I confirm that it's fixed.
Regards,
Ruslan
_
Hi Michael,
On Wed, Nov 21, 2012 at 7:09 PM, Michael Meeks wrote:
>
>> To get this all work more or less as expected (i.e. to fix oxygen-gtk
>> at correct time), I'd need to know, which LibO releases will contain
>> these commits. Any pointers to this?
>
> Is it an easy thing to check fro
On Mon, 2012-11-19 at 23:55 +0400, Ruslan Kabatsayev wrote:
> OK, it appears that these commits have made LibO work more correctly
> in GTK handling, and now oxygen-gtk's old hacks to work around
> previous LibO incorrectness overcompensate the margins and need to be
> removed.
Drat ... t
Hi,
So, background gradients are fixed now with
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0a5eed63b871e2febb36e27e9dea4b7e57f681b
Regards,
Ivan
On 01.11.2012 23:48, Ruslan Kabatsayev wrote:
> Some time after my commits, which enabled almost fully correct
> oxygen-gtk support (late
On 19.11.2012 23:55, Ruslan Kabatsayev wrote:
> Hi Ivan,
>
> OK, it appears that these commits have made LibO work more correctly
> in GTK handling, and now oxygen-gtk's old hacks to work around
> previous LibO incorrectness overcompensate the margins and need to be
> removed.
> To get this all wo
On Mon, 2012-11-19 at 23:45 +0100, Enrico Weigelt wrote:
> IIRC, this provides KDE look+feel using Gtk, right ?
> That, IMHO, could count as argument for dropping Qt/KDE vcl.
> (see my other postings about vcl's/widget toolkits)
Please stop trolling on this topic.
ATB,
On Tue, Nov 20, 2012 at 2:45 AM, Enrico Weigelt wrote:
>
> IIRC, this provides KDE look+feel using Gtk, right ?
> That, IMHO, could count as argument for dropping Qt/KDE vcl.
> (see my other postings about vcl's/widget toolkits)
Not quite KDE look&feel in general, rather only Oxygen widget style
Hi,
> Some time after my commits, which enabled almost fully correct
> oxygen-gtk support (latest commit was on Jul 8 2012), this support
> was
> broken. See screenshots at [1], [2], [3] and [4] for details.
> Those who hacked on GTK theming support since Jul 8 2012, please have
> a look at this.
Hi Ivan,
OK, it appears that these commits have made LibO work more correctly
in GTK handling, and now oxygen-gtk's old hacks to work around
previous LibO incorrectness overcompensate the margins and need to be
removed.
To get this all work more or less as expected (i.e. to fix oxygen-gtk
at corre
Hi Ruslan,
On 01.11.2012 23:48, Ruslan Kabatsayev wrote:
> Some time after my commits, which enabled almost fully correct
> oxygen-gtk support (latest commit was on Jul 8 2012), this support was
> broken. See screenshots at [1], [2], [3] and [4] for details.
The problem at [1] is due to the follo
Hello,
Some time after my commits, which enabled almost fully correct
oxygen-gtk support (latest commit was on Jul 8 2012), this support was
broken. See screenshots at [1], [2], [3] and [4] for details.
Those who hacked on GTK theming support since Jul 8 2012, please have
a look at this. If you th
20 matches
Mail list logo
