From: Emrys W. <emr...@ev...> - 2009-07-27 13:40:51
|
The media galleries in the Mac version of gramps I have been building have been acting oddly. This is 3.1.2 code. The first problem was that dropping items on a media gallery page would create two copies. Trying to move items around would produce unexpected results. This turned out to be the same bug as already fixed in the scratchpad code - two calls to the drag_data_received routine for each drop event. Does this not happen in linux builds of this code? The second problem was that the icons in the media gallery were sometimes oddly spaced. Rather than forming a pretty grid pattern, some icons took up exactly twice the space they should. This turned out to be the "set custom text cell renderer for better control" initialisation code. It specifies text_renderer.set_property('wrap-width', item_width) where item_width is 125. Pixels? Anyway, the captions are wrapped too wide. Captions that happen to wrap close to item_width cause the cell in which an icon is stored to double in size to accommodate the oversize caption. Is this because the wrap_width should be smaller to allow for the margins? Setting the wrap_width at 110 cured the problem for me. And, some captions beneath the icons were moved over a bit to the right of where they should have been. The code specifies text_renderer.set_property('alignment', pango.ALIGN_CENTER) and actually it didn't look like that, especially for very short captions. I tried instead text_renderer.set_property('alignment', pango.ALIGN_LEFT) and that worked perfectly - aligning the centre of the captions exactly with the center of the icons! I can't understand exactly how the C enum value PANGO_ALIGN_LEFT gets transferred to the python code pango.ALIGN_LEFT, to check just what's going on. Can someone explain how that happens? I'm trying to understand whether the odd behaviour of the media gallery pages is specific to Macs or is generic to all builds. Do linux builds sometimes give odd arrangements of the media gallery pages when the captions are quite long? Dropping a jpeg on a media gallery page - by dragging off my desktop, for example - creates a new gramps media object and adds it to the gallery, very nicely. But for me, this only works if there are already media obects in the gallery. If the media gallery is entirely empty, I can't drop the jpeg on it. Is this Mac-specific or general, please? Dropping a jpeg on a media gallery page where the jpeg filename has a space in it doesn't work, because the media object gets a filename where the space has been replaced by %20. Editing the %20 back to a space in the media reference editor fixes the issue. Again, is this Mac-specific or general, please? I want to understand if these bugs appear in linux versions so that I don't go making bug reports for problems I've caused in my own inept build process! I don't have a linux gramps. Mac release soon - promise! Thanks. Emrys |
From: Gary B. <bur...@ya...> - 2009-07-28 10:07:35
|
Hello Emrys > Does this not happen in linux builds of this code? I see some of these on my main server running Debian Testing - I get the widely spaced thumbnails and the 'can't drop an object unless there is already one there' thing. However the same code running on my eeePC is OK. Therefore I think these issues are GTK/pyGTK related and are just other changes in the dependencies that we have to workaround. This is one of the annoying facets of working with F/OSS that we are constantly having to spend time adapting GRAMPS to these types of changes. Bye Gary |
From: Emrys W. <emr...@ev...> - 2009-07-29 12:24:15
|
Are the captions somewhat off to the right? Especially short captions, like the single letter "i"? Thanks! Emrys Gary Burton wrote: > Hello Emrys > > > > >> Does this not happen in linux builds of this code? >> > > I see some of these on my main server running Debian Testing - I get the widely spaced thumbnails and the 'can't drop an object unless there is already one there' thing. However the same code running on my eeePC is OK. Therefore I think these issues are GTK/pyGTK related and are just other changes in the dependencies that we have to workaround. This is one of the annoying facets of working with F/OSS that we are constantly having to spend time adapting GRAMPS to these types of changes. > > Bye > > Gary > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Gary B. <bur...@ya...> - 2009-07-29 12:49:01
|
Hello Emrys > Are the captions somewhat off to the right? Especially short captions, > like the single letter "i"? Thanks! Emrys Yes, I see that too. Bye Gary |
From: Benny M. <ben...@gm...> - 2009-08-04 07:39:01
|
Emrys, I would like to see all patches for the mac build rolled back in the main branch, so that no patches must be applied to have GRAMPS working on mac. So if you could make bug tickets for each of them with code patches. >From Gary's remarks I take it that the issues you see here are present in linux too with the latest version of GTK/pygtk. If you can make a patch for the things you already solved and again attach to a bug ticket, we can take it further from there. If you make bug tickets, do also a mailing tread with the links to the bugs, as just adding a bug to the tracker can easily be lost in the large amount submitted there. Benny 2009/7/29, Gary Burton <bur...@ya...>: > > Hello Emrys > >> Are the captions somewhat off to the right? Especially short captions, >> like the single letter "i"? Thanks! Emrys > > Yes, I see that too. > > Bye > > Gary > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Emrys W. <emr...@ev...> - 2009-08-04 07:44:04
|
Yes, I have a whole pile of patches to create bug tickets for. We're just getting the PPC build to work and then we'll get to it. And, Benny, the scratchpad drag-and-drop fix you created earlier: please go ahead and check that into the trunk, all is fine there. Thanks! Emrys Benny Malengier wrote: > Emrys, > > I would like to see all patches for the mac build rolled back in the > main branch, so that no patches must be applied to have GRAMPS working > on mac. So if you could make bug tickets for each of them with code > patches. > > >From Gary's remarks I take it that the issues you see here are present > in linux too with the latest version of GTK/pygtk. If you can make a > patch for the things you already solved and again attach to a bug > ticket, we can take it further from there. > > If you make bug tickets, do also a mailing tread with the links to > the bugs, as just adding a bug to the tracker can easily be lost in > the large amount submitted there. > > Benny > > 2009/7/29, Gary Burton <bur...@ya...>: > >> Hello Emrys >> >> >>> Are the captions somewhat off to the right? Especially short captions, >>> like the single letter "i"? Thanks! Emrys >>> >> Yes, I see that too. >> >> Bye >> >> Gary >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Richard T. <rjt...@th...> - 2009-08-04 08:47:47
|
Benny To save Emrys time and effort could he roll out all the OS X related patches into a single issue? It seams a lot to ask for him to split everything up. If there are any controversial elements they can be spun out into separate issues to clear the way for the main patch. I am happy to commit the changes once they have been discussed. I can do the commits as separate, self contained patches. Emrys has already put a huge amount of work in to get the OS X build to work, I am just looking to reduce his work load in the final push if we possibly can. I also think that we should get the os x build script itself into svn, like the windows ones are. Then the OS X build can move towards a proper supported release. I want to use it as my primary development platform :-) Regards Richard Benny Malengier wrote: > Emrys, > > I would like to see all patches for the mac build rolled back in the > main branch, so that no patches must be applied to have GRAMPS working > on mac. So if you could make bug tickets for each of them with code > patches. > >>From Gary's remarks I take it that the issues you see here are present > in linux too with the latest version of GTK/pygtk. If you can make a > patch for the things you already solved and again attach to a bug > ticket, we can take it further from there. > > If you make bug tickets, do also a mailing tread with the links to > the bugs, as just adding a bug to the tracker can easily be lost in > the large amount submitted there. > > Benny > > 2009/7/29, Gary Burton <bur...@ya...>: >> Hello Emrys >> >>> Are the captions somewhat off to the right? Especially short captions, >>> like the single letter "i"? Thanks! Emrys >> Yes, I see that too. >> >> Bye >> >> Gary >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > |
From: Benny M. <ben...@gm...> - 2009-08-04 17:38:56
|
Richard, your suggestion is fine for me. My intend was that I would like a standard way to do platform dependent things and clean up his patches for that. If you could look for that specifically. In const.py.in I created LINUX, MACOS and WINDOWS variables, and in Utils.py the functions to use: lin(), mac() and win(). Also, it takes experience with the code base to know that some things can be changed for the linux branch likewise as for eg mac. Experience learns that patches from eg windows make windows work better leaving the linux experience the same, while it could also improve :-) But you have sufficient knowledge of the codebase to make that call. You can start with the patch in http://www.gramps-project.org/bugs/view.php?id=3089 which has one error, if True or mac(): should be if mac(): I used that to test it, as the mac way of doing things works just fine in linux too. I think the linux way offers some small advantage of knowing beforehand what will happen, though one can do in reality without that, but as I understand the drag and drop code (not much experience there) the way linux does it is the 'correct' way, so I would leave the code branch. Benny 2009/8/4, Richard Taylor <rjt...@th...>: > Benny > > To save Emrys time and effort could he roll out all the OS X related > patches into a single issue? It seams a lot to ask for him to split > everything up. If there are any controversial elements they can be spun > out into separate issues to clear the way for the main patch. > > I am happy to commit the changes once they have been discussed. I can do > the commits as separate, self contained patches. > > Emrys has already put a huge amount of work in to get the OS X build to > work, I am just looking to reduce his work load in the final push if we > possibly can. > > I also think that we should get the os x build script itself into svn, > like the windows ones are. Then the OS X build can move towards a proper > supported release. I want to use it as my primary development platform :-) > > Regards > > Richard > > > Benny Malengier wrote: >> Emrys, >> >> I would like to see all patches for the mac build rolled back in the >> main branch, so that no patches must be applied to have GRAMPS working >> on mac. So if you could make bug tickets for each of them with code >> patches. >> >>>From Gary's remarks I take it that the issues you see here are present >> in linux too with the latest version of GTK/pygtk. If you can make a >> patch for the things you already solved and again attach to a bug >> ticket, we can take it further from there. >> >> If you make bug tickets, do also a mailing tread with the links to >> the bugs, as just adding a bug to the tracker can easily be lost in >> the large amount submitted there. >> >> Benny >> >> 2009/7/29, Gary Burton <bur...@ya...>: >>> Hello Emrys >>> >>>> Are the captions somewhat off to the right? Especially short captions, >>>> like the single letter "i"? Thanks! Emrys >>> Yes, I see that too. >>> >>> Bye >>> >>> Gary >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus >>> on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > > |