gtk1-win-developers Mailing List for GTK1 for Windows
Brought to you by:
robinrowe
Menu
▾
▴
gtk1-win-developers — GTK1 for Windows Developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(3) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
(7) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Robin R. <rob...@ci...> - 2020-11-19 22:32:47
|
Anyone interested in GTK1 for Windows please join our #gtk1 channel... CinePaint Update: Version 1.4 builds on Windows and is in QA. Linux and MacOS versions coming. Website not updated yet. Letting insiders here know first. Stay Involved: Join CinePaint on Slack. This public link expires on 2020/12/19 or at the first 2,000 users. https://join.slack.com/t/cinepaint/shared_invite/zt-jc6mkohv-4Pv4Km8j0O0d7sfpPHpyog Cheers, Robin -- Robin Rowe CinePaint Project Manager Beverly Hills, California rob...@ci... imdb.me/robinrowe |
|
From: Robin R. <ro...@Mo...> - 2004-04-08 19:09:55
|
Tor Lillqvist writes: > Federico Mena Quintero writes: > > It looks like your main showstopper is the threading issue on Win32. > > Maybe you would like to invest some time in fixing it? > > And are you sure, Robin, that FLTK is any better in this regard? First, Federico is entirely mistaken that our main issue with GTK2 has to do with threading. Many projects rely upon gtk.org for support and you kindly help them when you can. You have another class of user that independently fixes bugs, is not waiting for anyone's support. We're in that group. The biggest issue for us with GTK is size. GTK2 has more lines of code (10mb+) than CinePaint (about 7mb of source code). Why should we need to allocate more QA resources to maintaining GTK than we do to our own project? Unintentionally that's what we've done, and it doesn't work. Our project came almost to a standstill as we struggled with GTK. It takes too much time to get our heads around GTK because there is too much of it. Our biggest motivation to migrate to FLTK is not features but that it is 30x smaller, a size we can handle. Regarding message deadlock in a Windows thread, the general solution to is to run a message pump in the thread to clear the queue. My code in CinePaint inadvertently put to sleep a thread that needs to be awake for a Windows call. That is my bug, not GTK. Upon reflection, I don't know that there is a threading problem in GTK. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Tor L. <tm...@ik...> - 2004-04-08 04:55:55
|
Federico Mena Quintero writes: > It looks like your main showstopper is the threading issue on Win32. > Maybe you would like to invest some time in fixing it? And are you sure, Robin, that FLTK is any better in this regard? I honestly don't know; if it is, I would be the first to admit that this would indeed be a very good reason to use it instead of GTK2, if CinePaint works in such a way that it needs to manipulate the same windows freely from different threads. (I will grab the FLTK 2.0 source from CVS and check how they handle this; maybe I can get some inspiration to finally fix it in GTK...) --tml |
|
From: Federico M. Q. <fed...@xi...> - 2004-04-07 19:51:16
|
On Tue, 2004-04-06 at 23:22, Robin Rowe wrote: > Ok, so long as everyone understands my reasons are not intended as > criticism, nor as a call for changes to GTK2. > > http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK I'm posting these comments here for the benefit of the other list members. You should really investigate moving CinePaint to GTK+ 2.4. 1.2 is really old, unsupported, and numerous bugfixes have gone in since then. There's a guide to porting apps from GTK+ 1.2 to 2.x: http://developer.gnome.org/dotplan/porting/ (Ignore the bits about GNOME; look at the GTK+ chapter.) Many changes can be done with a perl script to replace e.g. gtk_signal_connect with g_signal_connect. You can also replace obsolete APIs in stages by using the deprecation flags when building. At Ximian we had to port a lot of code that used GTK+ 1.2, during the time of the migration from GNOME 1.4 to GNOME 2.0, and it was reasonably easy to do. It's mostly grunt work. Feel free to ask if you get stuck. GTK+ has a large development community, even full-time paid hackers working on it, so you can be confident that it will always have people interested in keeping it up-to-date. It looks like your main showstopper is the threading issue on Win32. Maybe you would like to invest some time in fixing it? Changing to a completely unrelated toolkit is a very large job, especially for an app as big as CinePaint. Other toolkits will have the same problem on Win32, or they may already have a solution from which you can get inspiration. Federico |
|
From: Robin R. <ro...@Mo...> - 2004-04-07 04:23:18
|
Owen, > Well, I can't say I'm not disappointed about the switch to FLTK, though > it's your project... Care to give some reasoning why you decided to move > to a completely different toolkit, rather than one (GTK2) that is a lot > closer to the current codebase? Ok, so long as everyone understands my reasons are not intended as criticism, nor as a call for changes to GTK2. http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Owen T. <ot...@re...> - 2004-04-06 14:01:12
|
On Tue, 2004-04-06 at 01:13, Robin Rowe wrote: > Owen and Tor, >=20 > Hi. I just want to let you know that you seem to have been right from the > start about GTK1 for Windows, that it is simply too much work for me to > correct the problems there. I did learn a lot from working on it though. = I > am discontinuing my GTK1 for Windows effort so I can devote more time to > CinePaint. GTK+OSX is expected to keep going because it seems to be neari= ng > completion. >=20 > I hope you won't be disappointed that I'm not moving toward GTK2. Upon th= e > results of further research into our project's particular needs the new p= lan > for CinePaint is to transition to FLTK. Hi Robin, Well, I can't say I'm not disappointed about the switch to FLTK, though it's your project... Care to give some reasoning why you decided to move to a completely different toolkit, rather than one (GTK2) that is a lot closer to the current codebase? Regards, Owen |
|
From: Robin R. <ro...@Mo...> - 2004-04-06 05:14:09
|
Owen and Tor, Hi. I just want to let you know that you seem to have been right from the start about GTK1 for Windows, that it is simply too much work for me to correct the problems there. I did learn a lot from working on it though. I am discontinuing my GTK1 for Windows effort so I can devote more time to CinePaint. GTK+OSX is expected to keep going because it seems to be nearing completion. I hope you won't be disappointed that I'm not moving toward GTK2. Upon the results of further research into our project's particular needs the new plan for CinePaint is to transition to FLTK. Appreciate your past help and courtesy. Thanks for everything! Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Henning N. L. <hn...@st...> - 2004-03-22 09:06:58
|
Henning Nielsen Lund wrote: > Hi Robin, > > What backend do you use for gthreads? as there are different backends for gthreads (Win32) ... there is the Win32-thread backend ... and there is the pthreads backend. For the pthreads backend are there two libraries for win32: http://sources.redhat.com/pthreads-win32/ that has been used by gtk before they made the win32-thread backend. And there is GNU pth ( IIRC has there only been a CygWin port ) - http://www.ossp.org/pkg/lib/pth/ - that has a pthreads emulation. > > Best regards, > hnl_dk - Henning Nielsen Lund > > > Robin Rowe wrote: >> Donald, >> >>> As the post says there is a problem with multi-threaded apps. >> >> Good work tracking that down! >> >>> Does the >>> suggestion of having a thread in GTK that is always used to >>> create/change Windows seem like a good option to solve this >>> problem. >> >> Not really. GTK seems to have endless problems. Diverting more effort >> from CinePaint into GTK is not the answer. >> >> I have another idea I'm researching. >> >> Robin >> ------------------------------------------------------------------- >> Rob...@Mo... Hollywood, California >> www.CinePaint.org Open source digital motion picture film software >> >> ----- Original Message ----- >> From: "Donald MacVicar" <do...@dr...> >> To: <gtk...@li...> >> Sent: Thursday, March 18, 2004 3:27 PM >> Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers >> >> >>> Robin, >>> >>>>> Do you have a patch for these changes/bug-fixes? >>>>> >>>>> >>>> >>>> It's way too unstable to be useful to anyone I think. >>>> >>>> >>> Ok fair enough. >>> >>> I have been trying to get Cinepaint to work with your gtkwin1.4 but >>> am coming across a deadlock problem when running any of the load >>> plug-ings. I see a Bug note in layers_dialog.c which refers to the >>> gifload - but I see the same problem with tiff and jpeg (maybe >>> others, have not got round to trying them yet) >>> >>> WHen the plugin calls gimp_image_new( .... ) which ends up causing a >>> menu change for one of the the windows. Which calls the Win32 API >>> function MoveWindow( ) from the WireMsgHandler thread . The window >>> that this is being called for was created in the WinMain thread - >>> which is sitting waiting for the plugin to return. Hence we end up >>> in Deadlock. I found the following post from gtk-devel but there >>> seems to be little more on this. >>> >>> http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html >>> >>> As the post says there is a problem with multi-threaded apps. Does >>> the suggestion of having a thread in GTK that is always used to >>> create/change Windows seem like a good option to solve this >>> problem. >>> >>> Donald. >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IBM Linux Tutorials >>> Free Linux tutorial presented by Daniel Robbins, President and CEO >>> of GenToo technologies. Learn everything from fundamentals to system >>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>> _______________________________________________ >>> Gtk1-win-developers mailing list >>> Gtk...@li... >>> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers >>> >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Gtk1-win-developers mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers |
|
From: Henning N. L. <hn...@st...> - 2004-03-22 07:50:15
|
Hi Robin, What backend do you use for gthreads? Best regards, hnl_dk - Henning Nielsen Lund Robin Rowe wrote: > Donald, > >> As the post says there is a problem with multi-threaded apps. > > Good work tracking that down! > >> Does the >> suggestion of having a thread in GTK that is always used to >> create/change Windows seem like a good option to solve this problem. > > Not really. GTK seems to have endless problems. Diverting more effort > from CinePaint into GTK is not the answer. > > I have another idea I'm researching. > > Robin > ------------------------------------------------------------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Open source digital motion picture film software > > ----- Original Message ----- > From: "Donald MacVicar" <do...@dr...> > To: <gtk...@li...> > Sent: Thursday, March 18, 2004 3:27 PM > Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers > > >> Robin, >> >>>> Do you have a patch for these changes/bug-fixes? >>>> >>>> >>> >>> It's way too unstable to be useful to anyone I think. >>> >>> >> Ok fair enough. >> >> I have been trying to get Cinepaint to work with your gtkwin1.4 but >> am coming across a deadlock problem when running any of the load >> plug-ings. I see a Bug note in layers_dialog.c which refers to the >> gifload - but I see the same problem with tiff and jpeg (maybe >> others, have not got round to trying them yet) >> >> WHen the plugin calls gimp_image_new( .... ) which ends up causing a >> menu change for one of the the windows. Which calls the Win32 API >> function MoveWindow( ) from the WireMsgHandler thread . The window >> that this is being called for was created in the WinMain thread - >> which is sitting waiting for the plugin to return. Hence we end up >> in Deadlock. I found the following post from gtk-devel but there >> seems to be little more on this. >> >> http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html >> >> As the post says there is a problem with multi-threaded apps. Does >> the suggestion of having a thread in GTK that is always used to >> create/change Windows seem like a good option to solve this problem. >> >> Donald. >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Gtk1-win-developers mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers |
|
From: Robin R. <ro...@Mo...> - 2004-03-22 06:28:44
|
Donald, > As the post says there is a problem with multi-threaded apps. Good work tracking that down! > Does the > suggestion of having a thread in GTK that is always used to > create/change Windows seem like a good option to solve this problem. Not really. GTK seems to have endless problems. Diverting more effort from CinePaint into GTK is not the answer. I have another idea I'm researching. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software ----- Original Message ----- From: "Donald MacVicar" <do...@dr...> To: <gtk...@li...> Sent: Thursday, March 18, 2004 3:27 PM Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers > Robin, > > >>Do you have a patch for these changes/bug-fixes? > >> > >> > > > >It's way too unstable to be useful to anyone I think. > > > > > Ok fair enough. > > I have been trying to get Cinepaint to work with your gtkwin1.4 but am > coming across a deadlock problem when running any of the load > plug-ings. I see a Bug note in layers_dialog.c which refers to the > gifload - but I see the same problem with tiff and jpeg (maybe others, > have not got round to trying them yet) > > WHen the plugin calls gimp_image_new( .... ) which ends up causing a > menu change for one of the the windows. Which calls the Win32 API > function MoveWindow( ) from the WireMsgHandler thread . The window that > this is being called for was created in the WinMain thread - which is > sitting waiting for the plugin to return. Hence we end up in Deadlock. > I found the following post from gtk-devel but there seems to be little > more on this. > > http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html > > As the post says there is a problem with multi-threaded apps. Does the > suggestion of having a thread in GTK that is always used to > create/change Windows seem like a good option to solve this problem. > > Donald. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > > |
|
From: Donald M. <do...@dr...> - 2004-03-18 23:27:22
|
Robin, >>Do you have a patch for these changes/bug-fixes? >> >> > >It's way too unstable to be useful to anyone I think. > > Ok fair enough. I have been trying to get Cinepaint to work with your gtkwin1.4 but am coming across a deadlock problem when running any of the load plug-ings. I see a Bug note in layers_dialog.c which refers to the gifload - but I see the same problem with tiff and jpeg (maybe others, have not got round to trying them yet) WHen the plugin calls gimp_image_new( .... ) which ends up causing a menu change for one of the the windows. Which calls the Win32 API function MoveWindow( ) from the WireMsgHandler thread . The window that this is being called for was created in the WinMain thread - which is sitting waiting for the plugin to return. Hence we end up in Deadlock. I found the following post from gtk-devel but there seems to be little more on this. http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html As the post says there is a problem with multi-threaded apps. Does the suggestion of having a thread in GTK that is always used to create/change Windows seem like a good option to solve this problem. Donald. |
|
From: Robin R. <ro...@Mo...> - 2004-03-18 07:36:27
|
Donald, > Do you have a patch for these changes/bug-fixes? It's way too unstable to be useful to anyone I think. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Donald M. <do...@dr...> - 2004-03-17 12:50:06
|
Do you have a patch for these changes/bug-fixes? Donald. > -----Original Message----- > From: gtk...@li... > [mailto:gtk...@li...] On > Behalf Of Robin Rowe > Sent: 04 March 2004 07:03 > To: gtk...@li... > Subject: [Gtk1-win-developers] Progress - decloaked GDK pointers > > Hi. Hadn't found time to touch GTK1 for a couple months. Been > busy on other > things. > > My attempt to use GDK2 with GTK1 didn't work out. Am back > working on GDK1. > That has serious problems with releasing HDC handles with > live resources in > them, causing random crashes inside Windows. Same problem > we've known about > since last year. That GDK by design casts objects all over > the place defeats > debugging. This pointer cloaking had me a bit discouraged. > > Changed GTK1 this week to have all the by-design GTK pointer > cloaking turned > off so I can see clearly now what is going on. What that means is that > GdkWhatever, GdkWhateverPrivate, and GdkWhateverPrivateWin32 > are all the > same struct type now. In making that change I discovered one > place where an > up-cast was converting to a type larger than had been > allocated in memory. > One bug fixed. > > Testing with HelloGtk, my new decloaked GDK1 immediately > hurled on g_free, > which puzzled me a bit. Rewrote the basic g_... glib memory > handlers to > streamline them, but it still crashed. Then I realized that > for Windows apps > and dlls there are separate heaps, that you have to keep > malloc/free calls > symmetric to the caller's address space. In other words, no > calling local > free on a pointer malloc-ed inside a dll. Inadvertently, a > header file macro > was doing that. Making all g_... memory functions exported > dll functions > fixed it. > > Am encouraged that I seem to be back on the right track and > can see what's > going on while crawling around in the VC++ debugger and > BoundsChecker. Looks > like quite a few repairs ahead, but making progress. > > After the GTK1 HDC bugs are fixed I would like to work on > tablet support and > a new macro recorder feature. Been wanting to work on both of > those a long > time. > > Cheers, > > Robin > ------------------------------------------------------------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Open source digital motion picture film software > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > |
|
From: Robin R. <ro...@Mo...> - 2004-03-04 07:09:52
|
Hi. Hadn't found time to touch GTK1 for a couple months. Been busy on other things. My attempt to use GDK2 with GTK1 didn't work out. Am back working on GDK1. That has serious problems with releasing HDC handles with live resources in them, causing random crashes inside Windows. Same problem we've known about since last year. That GDK by design casts objects all over the place defeats debugging. This pointer cloaking had me a bit discouraged. Changed GTK1 this week to have all the by-design GTK pointer cloaking turned off so I can see clearly now what is going on. What that means is that GdkWhatever, GdkWhateverPrivate, and GdkWhateverPrivateWin32 are all the same struct type now. In making that change I discovered one place where an up-cast was converting to a type larger than had been allocated in memory. One bug fixed. Testing with HelloGtk, my new decloaked GDK1 immediately hurled on g_free, which puzzled me a bit. Rewrote the basic g_... glib memory handlers to streamline them, but it still crashed. Then I realized that for Windows apps and dlls there are separate heaps, that you have to keep malloc/free calls symmetric to the caller's address space. In other words, no calling local free on a pointer malloc-ed inside a dll. Inadvertently, a header file macro was doing that. Making all g_... memory functions exported dll functions fixed it. Am encouraged that I seem to be back on the right track and can see what's going on while crawling around in the VC++ debugger and BoundsChecker. Looks like quite a few repairs ahead, but making progress. After the GTK1 HDC bugs are fixed I would like to work on tablet support and a new macro recorder feature. Been wanting to work on both of those a long time. Cheers, Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Donald M. <do...@dr...> - 2003-12-22 11:36:37
|
> Donald, > > > Could you send me the MSVC dsp files you use to build glib and gtk > > etc. > > Different dsp files from the ones in the tarball? > Ahh found them. Thanks, Donald |
|
From: Robin R. <ro...@Mo...> - 2003-12-20 23:14:09
|
Donald, > Could you send me the MSVC dsp files you use to build glib and gtk > etc. Different dsp files from the ones in the tarball? Cheers, Robin --------------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Free motion picture and still image editing software |
|
From: Donald M. <do...@dr...> - 2003-12-18 14:44:29
|
Robin, Could you send me the MSVC dsp files you use to build glib and gtk etc. I can get it to compile but am having problems with the code in glib/glib/trio/trio.c - it segfaults when trying to read errno. Thanks, Donald. |
|
From: Donald M. <do...@dr...> - 2003-12-08 16:10:03
|
I have found a better solution to the "initializer element is not constant" problem that I was trying to solve. It seems that if gcc is allowed to use the auto import then everything works just fine. If under gcc the __declspec(dllimport) is removed then there is no problem. http://www.cygwin.com/ml/cygwin/2003-01/msg00056.html Donald. > -----Original Message----- > From: gtk...@li... > [mailto:gtk...@li...] On > Behalf Of Robin Rowe > Sent: 04 December 2003 01:06 > To: gtk...@li... > Subject: Re: [Gtk1-win-developers] casts > > Donald, > > > If we were to use g++ all cast would need to be made > explictly, would > > there be any objections to this? > > Sounds good, but I don't like bare casts because they are > tricky to find. > Can you use a macro like this? > > #define CAST(t) (t) > > float a = 1.0; > int b = CAST(int) a; > > I prefer that over the new C++ cast syntax. Simple, works in > C, easy to > grep. > > Cheers, > > Robin > -------------------------------------------------------------- > ------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Free motion picture and still image > editing software > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > |
|
From: Donald M. <do...@dr...> - 2003-12-08 14:53:56
|
I have put up patches for each directory, (except po and doc) if you want to see what difference it will make. Donald. > -----Original Message----- > From: gtk...@li... > [mailto:gtk...@li...] On > Behalf Of Robin Rowe > Sent: 05 December 2003 18:04 > To: gtk...@li... > Subject: Re: [Gtk1-win-developers] GLIB 2.2.3 > > Donald, > > > I could provide a patch from the gtk1-win glib which can be > applied to > glib > > 2.2.3 it is pretty small 90k (as txt), and a second patch to fix the > > rejects? > > Don't bother. I'll provide a patch of my minor GLIB 2.2.1 > changes since GTK > 1.4. You apply that to your version of GLIB 2.2.3 and make a > new 2.2.3 patch > that includes all our changes. Then I'll download 2.2.3 and apply your > master patch. > > Cheers, > > Robin > -------------------------------------------------------------- > ------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Free motion picture and still image > editing software > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > |
|
From: Robin R. <ro...@Mo...> - 2003-12-05 18:04:06
|
Donald, > I could provide a patch from the gtk1-win glib which can be applied to glib > 2.2.3 it is pretty small 90k (as txt), and a second patch to fix the > rejects? Don't bother. I'll provide a patch of my minor GLIB 2.2.1 changes since GTK 1.4. You apply that to your version of GLIB 2.2.3 and make a new 2.2.3 patch that includes all our changes. Then I'll download 2.2.3 and apply your master patch. Cheers, Robin --------------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Free motion picture and still image editing software |
|
From: Donald M. <do...@dr...> - 2003-12-05 13:45:57
|
Robin, > > > > > > Sounds fine. I can send a patch for the glib that is there > > to 2.2.3 if you > > > like? > > > > Yes, please send to SF Patches. > > > I tried to put the patch on SF but it is too big (256k limit) and it is 800K as a gzip file. Do you have any suggestions? I could provide a patch from the gtk1-win glib which can be applied to glib 2.2.3 it is pretty small 90k (as txt), and a second patch to fix the rejects? Cheers, Donald. |
|
From: Robin R. <ro...@Mo...> - 2003-12-05 07:39:28
|
Donald, > So you build all of glib as one big dll and not 3 separate ones - glib, > gthread, gobject and gmodule? I guess that make sense. Yes, but it isn't much difference. It makes glib go from 350k to 420k. > Yeah I could do that - but....I have a fix for gmodule that allows it to > work, I just made it the same > as gobject (also a separate DLL) where GOBJECT_VAR is used for the > import/export of dll functions based on other defines. If you've got a better idea that's fine. We want to be as compatible with gtk.org as is practical. Cheers, Robin --------------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Free motion picture and still image editing software |
|
From: Donald M. <do...@dr...> - 2003-12-04 23:15:01
|
Robin Rowe wrote: >Donald, > > > >>In your dll_api.h only WIN32 and DLL_EXPORT are enough to cause symbols to >>be defined as declspec(dllexport). >>If you were then to build another dll based on this then they would be >>re-exported from the second dll... >> >> > >Ah, I think I see what the significant difference is now. In MSVC I only >build three dlls: gtk.lib, gdk.lib, and glib.lib. I don't build gmodule as a >separate dll. I have gmodule built into glib. > > So you build all of glib as one big dll and not 3 separate ones - glib, gthread, gobject and gmodule? I guess that make sense. >How about doing the same in cgwin? > > Yeah I could do that - but would make the automake stuff very different from the main glib. How much are you looking to be able to feed this work back into the main glib? Also how cross platform does it need to be? Will this code need to compile on Linux or others? I have a fix for gmodule that allows it to work, I just made it the same as gobject (also a separate DLL) where GOBJECT_VAR is used for the import/export of dll functions based on other defines. I added a #define section to gmodule.h much the same as the one in gobject/gparamspecs.h which seems to work, you can then still use G_MODULE_EXPORT and G_MODULE_IMPORT in the plugin dll's that use it. Will make sure the tests all pass tomorrow, libtool still causes a few issues when using mingw. Donald. |
|
From: Robin R. <ro...@Mo...> - 2003-12-04 20:53:51
|
Donald, > In your dll_api.h only WIN32 and DLL_EXPORT are enough to cause symbols to > be defined as declspec(dllexport). > If you were then to build another dll based on this then they would be > re-exported from the second dll... Ah, I think I see what the significant difference is now. In MSVC I only build three dlls: gtk.lib, gdk.lib, and glib.lib. I don't build gmodule as a separate dll. I have gmodule built into glib. How about doing the same in cgwin? Cheers, Robin --------------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Free motion picture and still image editing software |
|
From: Donald M. <do...@dr...> - 2003-12-04 15:55:48
|
> -----Original Message----- > From: gtk...@li... > [mailto:gtk...@li...] On > Behalf Of Robin Rowe > Sent: 04 December 2003 15:14 > To: gtk...@li... > Subject: Re: [Gtk1-win-developers] GLIB 2.2.3 > > Donald, > > > Downloaded both glib-2.2.1 and 2.2.3 from ftp.gtk.org and > made patch based > > on this. > > > > Was easy - just a few rejects. > > Good. > > > From looking at the diffs it seems that the main > > Difference is that you add GLIB_VAR for many more functions > than in the > real > > distro. > > That's right. > > FYI, once we have 1.4 stable I will go back to GTK and get > changes into CVS > there. > > > It is these that are giving me problems sometimes, eg in > gmodule/gmodule.h > > GLIB_VAR is not set as dllexport because we are not > compiling glib so no > > -DGLIB_COMPILATION and this is required in glib/gtypes.h to get the > correct > > setting to export these functions. If -DGLIB_COMPILATION is > set the other > > symbols also get exported from gmodule, e.g. glib_*_version > which causes > > problems at runtime. > > > > Gmodule.h does have the start of the correct way to handle > this, but does > > not depend on DLL_EXPORT. > > Can you explain what the extra plumbing with GLIB_COMPILATION > does in glib? > Why not like DLL_API that I implemented in dll_api.h in gtk? In your dll_api.h only WIN32 and DLL_EXPORT are enough to cause symbols to be defined as declspec(dllexport). If you were then to build another dll based on this then they would be re-exported from the second dll, this would compile and link quite happily but will be unpredictable at runtime - depends on the order the libraries were specified on the link command line. Since glib is being built as a dll and then used to link against in another dll and the gtypes.h header is used by all then the above problem exists. > > > Sounds fine. I can send a patch for the glib that is there > to 2.2.3 if you > > like? > > Yes, please send to SF Patches. > > Cheers, > > Robin > -------------------------------------------------------------- > ------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Free motion picture and still image > editing software > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > |
