Re: ABI report for Glibmm, Pangomm and Cairomm

[Andrey Ponomarenko]

Added report for Gtkmm: https://abi-laboratory.pro/tracker/timeline/gtkmm/ 24.06.2016, 17:15, "Ponomarenko Andrey":Hello,The Glibmm, Pangomm and Cairomm libraries have been added recently to the upstream ABI tracker project. The tracker performs backward binary compatibility analysis for the recent versions of libraries:http://abi-laboratory.pro/tracker/timeline/glibmm/http://abi-laboratory.pro/tracker/timeline/pangomm/http://abi-laboratory.pro/tracker/timeline/cairomm/The reports are generated daily with the help of the abi-compliance-checker and abi-tracker tools: https://github.com/lvc/abi-trackerHope this will help users, maintainers and developers of libraries to maintain backward compatibility.Thank you.___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTKMM for Windows - Informations request

[D. B.]

>
> One question: does using MSYS2 to generate the binaries generate a
> dependency on Cygwin library (dll)? If yes, that does not fit the purpose
> of having a native Windows environment.


Of course it doesn't fit, and that's why it doesn't happen! MSYS2 also
provides mingw-w32 and -w64 shells with compilers that link directly
against the native runtimes (unless you told them otherwise, I guess)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTKMM for Windows - Informations request

[Tom Schoonjans]

Hi Julius,


> On 27 Dec 2016, at 14:09, Julius Lawson  wrote:
> 
> Hi Tom,
> 
> I'm a colleague of Romain. Thanks to you, and all others, for the answers.
> 
> What came out of our search is that there is no one-click Gtkmm development 
> environment installer on WIndows which is continuously maintained. All 
> efforts have been interrupted at some point in time because the maintainers 
> get exhausted or some of the tools or components they based their work on 
> were discontinued. This is the "nice volunteer suffered a burn out: next one" 
> situation.

Well I like to think that my runtime installer is pretty well maintained :-) 
And with my transition to MSYS2, I will be able to make even more frequent 
releases as I won’t have to spend a weekend compiling the gtkmm2 and gtkmm3 
stacks :-)
The MSYS2 development environment is pretty solid, and has quite a large number 
of people contributing to it.
Also, whenever you think a project is useful but looks like it is not properly 
supported anymore, consider stepping in and bringing it back to life. This is 
how open source works and there is absolutely nothing wrong with that.

> 
> Ideally, we would like to set up a continuous integration system which would 
> automatically checkout sources from official repositories, build binaries, 
> package them into an installer and make the installer available to the 
> community. Therefore no more "nice volunteer suffered a burn out: next one" 
> situation.
> 

Appveyor is currently the most used CI system for Windows, but compiling the 
complete gtkmm2/3 stack on them will not work as you will hit the one hour time 
limit before it’s finished building all packages. 
You shouldn’t have to build the gtkmm2/3 stack yourself though, as you can use 
the binary packages offered by MSYS2, which are usually updated quite quickly 
after they are officially released. In case there is a delay in updating the 
packages, open a PR yourself at https://github.com/Alexpux/MINGW-packages/pulls


> To achieve this without reinventing the wheel, we were interested in being 
> pointed to a good starting point. Your project seems to be the good candidate 
> because it seems to be the most up to date. So up to date that we wonder if 
> our proposal to set up a CI system is still meaningful for the community. Let 
> us know...
> 

Well, with the migration to MSYS2-MINGW64 it should take me 15 minutes or so to 
make new Gtkmm2/3 runtime installers. If I do that once a month, I think 
everybody will be satisfied.
Keep also in mind that very often packages in the gtkmm2/3 stack need patching 
before they can be compiled or work properly on Windows…
If you would like to create a CI system that builds all these packages from 
scratch, you will need to spend quite some time gathering the sometimes 
necessary patches, or writing them yourself… I have been doing this up to now 
and I can assure you there is no fun in doing so. The packages provided by 
MSYS2 were compiled from patched source code and should work properly, which 
often explains why there was a bit of a delay before updates become visible in 
the package list.


> One question: does using MSYS2 to generate the binaries generate a dependency 
> on Cygwin library (dll)? If yes, that does not fit the purpose of having a 
> native Windows environment.
> 

No absolutely not: MSYS2 has nothing to do with cygwin. I recommend you read 
https://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin
 where the different versions that are offered by MSYS2 are explained in great 
detail. I use only the MSYS2-MINGW64 toolchain generated packages.

> Once again, thanks to you all.
> 

Best regards,

Tom

> Julius
> 
> 
> De: "Tom Schoonjans" 
> À: "John Emmas" 
> Cc: "Romain CENDRE" , "gtkmm-list" 
> 
> Envoyé: Lundi 26 Décembre 2016 14:20:05
> Objet: Re: GTKMM for Windows - Informations request
> 
> Hi,
> 
> I am the maintainer of the GTK for Windows Runtime Environment Installer 
> 64-bit project 
> (https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer 
> ), 
> which provides two installers for the full Gtkmm2 and Gtkmm3 stacks, as well 
> as some other often used packages such as libxml++, libxml2 and libxslt.
> 
> Installing either of these packages will optionally modify the PATH variable 
> so it will get picked up by your software. Alternatively, it can be included 
> in your own software installer, and unpackaged in the same folder as your own 
> dlls and/or executables.
> 
> The current stable packages were compiled from source by myself, but due to 
> the big effort involved, and due to the fact that the TDM-GCC compiler I used 
> seems unmaintained at this point, I am currently migrating to new versions of 
> the installers that 

Time in Glibmm and libgdamm

[Pavlo Solntsev]

Hi, (my first email didn't go well)

My question about Glibmm and libgdamm. I code only in c++. I faced this
problem when I wanted to save Date and Time into SQL database using
libgdamm. SQL by itself provides two types: DATE and TYPE. They are
good match for Glib::Date class, which already exist, and Glib::Time,
which doesn't exist. 

I can use GdaTime via std::time_t but this is ugly way for OO. Some
other libraries including boost provide class to handle time.

Could please explain me, why we have this situation with Time? It is so
ambiguous and confusing. I will be glad to help with implementation of
Glib::Time class. 
I would like a solution where Glib::Time and Glib::Date classes are
parent classes for Glib::DataTime. It will allow to manipulate DATATIME
type in SQL. 

Thanks.

From documentation:

typedef gint32  GTime;
Simply a replacement for time_t. It has been deprecated since it is not
equivalent to time_t on 64-bit platforms with a 64-bit time_t.
Unrelated to GTimer.
Note that GTime is defined to always be a 32-bit integer, unlike time_t
which may be 64-bit on some systems. Therefore, GTime will overflow in
the year 2038, and you cannot use the address of a GTime variable as
argument to the UNIX time() function.


Some time related classes found in Glib and Gnome::Gda namespace
1) Glib::Date
2) Glib::DateTime
3) Glib::TimeVal
4) Gnome::Gda::Timestemp ( or GdaTimestamp)
5) Gnome::Gda::Time ( or GdaTime)

Another unrelated topic. Since libgda will be developed by itself, it
would be clearer to have all class in Gda namespace. For back
compatibility, we may typedef Gda namespace to Gnome::Gda. 


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTKMM for Windows - Informations request

[Julius Lawson]

Hi Tom, 

I'm a colleague of Romain. Thanks to you, and all others, for the answers. 

What came out of our search is that there is no one-click Gtkmm development 
environment installer on WIndows which is continuously maintained. All efforts 
have been interrupted at some point in time because the maintainers get 
exhausted or some of the tools or components they based their work on were 
discontinued. This is the "nice volunteer suffered a burn out: next one" 
situation. 

Ideally, we would like to set up a continuous integration system which would 
automatically checkout sources from official repositories, build binaries, 
package them into an installer and make the installer available to the 
community. Therefore no more "nice volunteer suffered a burn out: next one" 
situation. 

To achieve this without reinventing the wheel, we were interested in being 
pointed to a good starting point. Your project seems to be the good candidate 
because it seems to be the most up to date. So up to date that we wonder if our 
proposal to set up a CI system is still meaningful for the community. Let us 
know... 

One question: does using MSYS2 to generate the binaries generate a dependency 
on Cygwin library (dll)? If yes, that does not fit the purpose of having a 
native Windows environment. 

Once again, thanks to you all. 

Julius 



De: "Tom Schoonjans"  
À: "John Emmas"  
Cc: "Romain CENDRE" , "gtkmm-list" 
 
Envoyé: Lundi 26 Décembre 2016 14:20:05 
Objet: Re: GTKMM for Windows - Informations request 

Hi, 

I am the maintainer of the GTK for Windows Runtime Environment Installer 64-bit 
project ( 
https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer ), 
which provides two installers for the full Gtkmm2 and Gtkmm3 stacks, as well as 
some other often used packages such as libxml++, libxml2 and libxslt. 

Installing either of these packages will optionally modify the PATH variable so 
it will get picked up by your software. Alternatively, it can be included in 
your own software installer, and unpackaged in the same folder as your own dlls 
and/or executables. 

The current stable packages were compiled from source by myself, but due to the 
big effort involved, and due to the fact that the TDM-GCC compiler I used seems 
unmaintained at this point, I am currently migrating to new versions of the 
installers that extract the required files from an MSYS2-MINGW64 installation. 
More information about this migration at 
https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/pull/6
 

Best, 

Tom 





On 26 Dec 2016, at 11:32, John Emmas < j...@creativepost.co.uk > wrote: 

On 26/12/2016 08:02, Romain CENDRE wrote: 

BQ_BEGIN


the company for which I'm working for, is interested in making build of GTKMM 
for Windows and I think that's not an easy part. 
And I'm asking you for all informations that can help us to do this job and 
support this lib for Windows platform. 




As someone who regularly builds gtkmm on Windows I initially found this message 
a bit confusing. Admittedly, though... I'm still building gtkmm version 2. But 
when I typed "gtkmm" and "windows" into Google, I soon realised that a lot of 
the links seem to end up in a page which says "this page has not been created 
yet". Binary packages (i.e. pre-built libraries) do exist though:- 

http://www.gtkmm.org/en/download.shtml#Binary 

So maybe there's been some delay in creating the various information pages?? 

Anyway Romain - you'll need to consider which compiler you want to use. MSVC 
and mingw (gcc) are both supported. Maybe someone will correct me here - but 
from a look at my own installation, VC5, VC8 and VC10 are the only MSVC 
compilers supported currently (for gtkmm v2). And (I'm guessing here...) the 
pre-built binary packages are most likely built with gcc. They're probably okay 
to get you started - but if you're building your app with (say) MSVC10, you 
should ultimately aim to build your GTK libs with the same compiler. 

Remember also that you'll need libraries which match your app (64-bit libs for 
a 64-bit app or 32-bit libs for a 32-bit app). 

And don't forget that libgtkmm isn't a stand-alone library. It needs other 
dependencies, such as libglib / libgtk / libsigc++ etc, etc. A guy called 
Tarnyko is probably one of the most prolific supporters of GTK/GTKMM for 
Windows. Search in Google for "tarnyko" and "gtk". 

John 
___ 
gtkmm-list mailing list 
gtkmm-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/gtkmm-list 

BQ_END



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Time in Glibmm and libgdamm

[D. B.]

FYI, it looks like some kind of space character in your original email has
been changed to a question mark symbol throughout, which makes it hard to
read, at least here on GMail. Maybe you could reconfigure your email at the
sending side to avoid this. Hope this helps!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list