GNOME.org
 

[shotwell] all: Replace a couple of yorba.org links

commit 8fde4cc67dab9ea45a954749b28940d74bc2f892
Author: Jens Georg <mail jensge org>
Date:   Sat Mar 14 07:30:15 2020 +0100

    all: Replace a couple of yorba.org links

 plugins/shotwell-publishing/FlickrPublishing.vala | 10 ++++------
 src/CheckerboardLayout.vala                       |  2 +-
 src/Debug.vala                                    |  2 +-
 src/Dialogs.vala                                  |  2 +-
 src/VideoMetadata.vala                            |  2 +-
 src/camera/GPhoto.vala                            |  4 ++--
 src/db/PhotoTable.vala                            |  2 +-
 src/main.vala                                     |  2 +-
 src/photos/PhotoMetadata.vala                     | 14 +++++++-------
 src/publishing/PublishingUI.vala                  | 20 +++++++++++---------
 src/util/string.vala                              |  4 ++--
 11 files changed, 32 insertions(+), 32 deletions(-)
---
diff --git a/plugins/shotwell-publishing/FlickrPublishing.vala 
b/plugins/shotwell-publishing/FlickrPublishing.vala
index d9b6563c..dc320332 100644
--- a/plugins/shotwell-publishing/FlickrPublishing.vala
+++ b/plugins/shotwell-publishing/FlickrPublishing.vala
@@ -802,16 +802,14 @@ internal class Uploader : Publishing.RESTSupport.BatchUploader {
 
             string[] all_keywords = keyword_set.to_array();
             // append a null pointer to the end of all_keywords -- this is a necessary workaround
-            // for http://trac.yorba.org/ticket/3264. See also http://trac.yorba.org/ticket/3257,
-            // which describes the user-visible behavior seen in the Flickr Connector as a result
-            // of the former bug.
+            // https://bugzilla.gnome.org/show_bug.cgi?id=712479. See also
+            // https://bugzilla.gnome.org/show_bug.cgi?id=717438 which describes the user-visible
+            // behavior seen in the Flickr Connector as a result of the former bug.
             all_keywords += null;
 
             string[] no_keywords = new string[1];
             // append a null pointer to the end of no_keywords -- this is a necessary workaround
-            // for http://trac.yorba.org/ticket/3264. See also http://trac.yorba.org/ticket/3257,
-            // which describes the user-visible behavior seen in the Flickr Connector as a result
-            // of the former bug.
+            // for similar reasons as above.
             no_keywords[0] = null;
             
             publishable_metadata.set_tag_multiple("Xmp.dc.subject", all_keywords);
diff --git a/src/CheckerboardLayout.vala b/src/CheckerboardLayout.vala
index 0bd80723..85232f37 100644
--- a/src/CheckerboardLayout.vala
+++ b/src/CheckerboardLayout.vala
@@ -18,7 +18,7 @@ public class CheckerboardLayout : Gtk.DrawingArea {
     // The number of pixels that the scrollbars of Gtk.ScrolledWindows allocate for themselves
     // before their final size is computed. This must be taken into account when computing
     // the width of this widget. This value was 0 in Gtk+ 2.x but is 1 in Gtk+ 3.x. See
-    // ticket #3870 (http://redmine.yorba.org/issues/3870) for more information
+    // ticket #3870 (https://bugzilla.gnome.org/show_bug.cgi?id=717754) for more information
     private const int SCROLLBAR_PLACEHOLDER_WIDTH = 1;
     
     private class LayoutRow {
diff --git a/src/Debug.vala b/src/Debug.vala
index a4104232..799a94f9 100644
--- a/src/Debug.vala
+++ b/src/Debug.vala
@@ -33,7 +33,7 @@ namespace Debug {
         
         string log_file_error_msg = null;
         
-        // logging to disk is currently off for viewer more; see http://trac.yorba.org/ticket/2078
+        // logging to disk is currently off for viewer more; see 
https://bugzilla.gnome.org/show_bug.cgi?id=716474
         File? log_file = (log_app_version_prefix == LIBRARY_PREFIX) ? AppDirs.get_log_file() : null;
         if(log_file != null) {
             File log_dir = log_file.get_parent();
diff --git a/src/Dialogs.vala b/src/Dialogs.vala
index 9b9fbcc6..3a223688 100644
--- a/src/Dialogs.vala
+++ b/src/Dialogs.vala
@@ -5,7 +5,7 @@
  */
 
 // namespace for future migration of AppWindow alert and other question dialogs into single
-// place: http://trac.yorba.org/ticket/3452
+// place: https://bugzilla.gnome.org/show_bug.cgi?id=717659
 namespace Dialogs {
 
 public bool confirm_delete_tag(Tag tag) {
diff --git a/src/VideoMetadata.vala b/src/VideoMetadata.vala
index 49ba8eff..6e6040b0 100644
--- a/src/VideoMetadata.vala
+++ b/src/VideoMetadata.vala
@@ -162,7 +162,7 @@ private class QuickTimeMetadataLoader {
         // QuickTime movie with a negative timestamp, we can be pretty sure it isn't a valid
         // QuickTime movie that was shot before 1904 but is instead a non-compliant 3GP video
         // file. If we detect such a video, we correct its time. See this Redmine ticket
-        // (http://redmine.yorba.org/issues/3314) for more information.
+        // (https://bugzilla.gnome.org/show_bug.cgi?id=717384) for more information.
         if (timestamp < 0)
             timestamp += QUICKTIME_EPOCH_ADJUSTMENT;
         
diff --git a/src/camera/GPhoto.vala b/src/camera/GPhoto.vala
index 39b2109e..aa2fcf2b 100644
--- a/src/camera/GPhoto.vala
+++ b/src/camera/GPhoto.vala
@@ -93,7 +93,7 @@ namespace GPhoto {
     }
 
     // For CameraFileInfoFile, CameraFileInfoPreview, and CameraStorageInformation.  See:
-    // http://redmine.yorba.org/issues/1851
+    // https://bugzilla.gnome.org/show_bug.cgi?id=716252
     // https://bugzilla.redhat.com/show_bug.cgi?id=585676
     // https://sourceforge.net/tracker/?func=detail&aid=3000198&group_id=8874&atid=108874
     public const int MAX_FILENAME_LENGTH = 63;
@@ -133,7 +133,7 @@ namespace GPhoto {
 
     // Libgphoto will in some instances refuse to get metadata from a camera, but the camera is accessible 
as a
     // filesystem.  In these cases shotwell can access the file directly. See:
-    // http://redmine.yorba.org/issues/2959
+    // https://bugzilla.gnome.org/show_bug.cgi?id=716915
     public PhotoMetadata? get_fallback_metadata(Camera camera, Context context, string folder, string 
filename) {
         GPhoto.CameraStorageInformation *sifs = null;
         int count = 0;
diff --git a/src/db/PhotoTable.vala b/src/db/PhotoTable.vala
index 72e43e79..79f6ec1b 100644
--- a/src/db/PhotoTable.vala
+++ b/src/db/PhotoTable.vala
@@ -391,7 +391,7 @@ public class PhotoTable : DatabaseTable {
     // the DB as a zero due to Vala 0.14 breaking the way it handled
     // objects passed as 'ref' arguments to methods. 
     // 
-    // For further details, please see http://redmine.yorba.org/issues/4354 and 
+    // For further details, please see https://bugzilla.gnome.org/show_bug.cgi?id=718194 and
     // https://bugzilla.gnome.org/show_bug.cgi?id=663818 .
     private void validate_orientation(PhotoRow row) {
         if ((row.orientation < Orientation.MIN) ||
diff --git a/src/main.vala b/src/main.vala
index 78611ca6..5a55cd86 100644
--- a/src/main.vala
+++ b/src/main.vala
@@ -355,7 +355,7 @@ void main(string[] args) {
 
     // This has to be done before the AppWindow is created in order to ensure the XMP
     // parser is initialized in a thread-safe fashion; please see 
-    // http://redmine.yorba.org/issues/4120 for details.
+    // https://bugzilla.gnome.org/show_bug.cgi?id=717931 for details.
     GExiv2.initialize();
     GExiv2.log_use_glib_logging();
 
diff --git a/src/photos/PhotoMetadata.vala b/src/photos/PhotoMetadata.vala
index bcd78fea..70a83e3f 100644
--- a/src/photos/PhotoMetadata.vala
+++ b/src/photos/PhotoMetadata.vala
@@ -462,7 +462,7 @@ public class PhotoMetadata : MediaMetadata {
     // NOTE: get_tag_multiple() in gexiv2 currently does not work with EXIF tags (as EXIF can 
     // never return a list of strings).  It will quietly return NULL if attempted.  Until fixed
     // (there or here), don't use this function to access EXIF.  See:
-    // http://trac.yorba.org/ticket/2966
+    // https://gitlab.gnome.org/GNOME/gexiv2/issues/10
     public Gee.List<string>? get_string_multiple(string tag) {
         string[] values = exiv2.get_tag_multiple(tag);
         if (values == null || values.length == 0)
@@ -489,7 +489,7 @@ public class PhotoMetadata : MediaMetadata {
     // NOTE: get_tag_multiple() in gexiv2 currently does not work with EXIF tags (as EXIF can 
     // never return a list of strings).  It will quietly return NULL if attempted.  Until fixed
     // (there or here), don't use this function to access EXIF.  See:
-    // http://trac.yorba.org/ticket/2966
+    // https://gitlab.gnome.org/GNOME/gexiv2/issues/10
     public Gee.List<string>? get_first_string_multiple(string[] tags) {
         foreach (string tag in tags) {
             Gee.List<string>? values = get_string_multiple(tag);
@@ -556,9 +556,9 @@ public class PhotoMetadata : MediaMetadata {
             return;
 
         // append a null pointer to the end of the string array -- this is a necessary
-        // workaround for http://trac.yorba.org/ticket/3264. See also
-        // http://trac.yorba.org/ticket/3257, which describes the user-visible behavior
-        // seen in the Flickr Connector as a result of the former bug.
+        // workaround for https://bugzilla.gnome.org/show_bug.cgi?id=712479. See also
+        // https://bugzilla.gnome.org/show_bug.cgi?id=717438, which describes the
+        // user-visible behavior seen in the Flickr Connector as a result of the former bug.
         values += null;
         
         if (!exiv2.set_tag_multiple(tag, values))
@@ -917,7 +917,7 @@ public class PhotoMetadata : MediaMetadata {
     // (sometimes) appropriate tag for the description.  And there's general confusion about
     // whether Exif.Image.ImageDescription is a description (which is what the tag name
     // suggests) or a title (which is what the specification states).
-    // See: http://trac.yorba.org/wiki/PhotoTags
+    // See: https://wiki.gnome.org/Apps/Shotwell/PhotoTags
     //
     // Hence, the following logic tries to do the right thing in most of these cases.  If
     // the iPhoto title tag is detected, it and the iPhoto description tag are used.  Otherwise,
@@ -1338,7 +1338,7 @@ public class PhotoMetadata : MediaMetadata {
     // Other photo managers, notably F-Spot, take hints from Urgency fields about what the rating
     // of an imported photo should be, and we have decided to do as well. Xmp.xmp.Rating is the only 
     // field we've seen photo manages export ratings to, while Urgency fields seem to have a fundamentally
-    // different meaning. See http://trac.yorba.org/wiki/PhotoTags#Rating for more information.
+    // different meaning. See https://wiki.gnome.org/Apps/Shotwell/PhotoTags#Rating for more information.
     public void set_rating(Rating rating) {
         int int_rating = rating.serialize();
         set_string("Xmp.xmp.Rating", int_rating.to_string());
diff --git a/src/publishing/PublishingUI.vala b/src/publishing/PublishingUI.vala
index b9081375..7aacb3d3 100644
--- a/src/publishing/PublishingUI.vala
+++ b/src/publishing/PublishingUI.vala
@@ -245,15 +245,17 @@ public class PublishingDialog : Gtk.Dialog {
         return filtered_services;
     }
 
-    // Because of this bug: http://trac.yorba.org/ticket/3623, we use some extreme measures. The
-    // bug occurs because, in some cases, when publishing is started asynchronous network 
-    // transactions are performed. The mechanism inside libsoup that we use to perform asynchronous
-    // network transactions isn't based on threads but is instead based on the GLib event loop. So
-    // whenever we run a network transaction, the GLib event loop gets spun. One consequence of
-    // this is that PublishingDialog.go( ) can be called multiple times. Note that since events
-    // are processed sequentially, PublishingDialog.go( ) is never called re-entrantly. It just
-    // gets called twice back-to-back in quick succession. So use a timer to do a short circuit
-    // return if this call to go( ) follows immediately on the heels of another call to go( ).
+    // Because of this bug: https://bugzilla.gnome.org/show_bug.cgi?id=717505, we use some
+    // extreme measures. The bug occurs because, in some cases, when publishing is started
+    // asynchronous network transactions are performed. The mechanism inside libsoup that we
+    // use to perform asynchronous network transactions isn't based on threads but is instead
+    // based on the GLib event loop. So whenever we run a network transaction, the GLib event
+    // loop gets spun. One consequence of this is that PublishingDialog.go( ) can be called
+    // multiple times. Note that since events are processed sequentially, PublishingDialog.go()
+    // is never called re-entrantly. It just gets called twice back-to-back in quick
+    // succession. So use a timer to do a short circuit return if this call to go( ) follows
+    // immediately on the heels of another call to go( )
+    // FIXME: Port publising to async libsoup, then there is no nested main loop anymore.
     private static Timer since_last_start = null;
     private static bool elapsed_is_valid = false;
     public static void go(Gee.Collection<MediaSource> to_publish) {
diff --git a/src/util/string.vala b/src/util/string.vala
index bf7e6054..0ff60f05 100644
--- a/src/util/string.vala
+++ b/src/util/string.vala
@@ -145,7 +145,7 @@ public string? prepare_input_text(string? text, PrepareInputTextOptions options,
     // Using composed form rather than GLib's default (decomposed) as NFC is the preferred form in
     // Linux and WWW.  More importantly, Pango seems to have serious problems displaying decomposed
     // forms of Korean language glyphs (and perhaps others).  See:
-    // http://trac.yorba.org/ticket/2952
+    // https://bugzilla.gnome.org/show_bug.cgi?id=716914
     if ((options & PrepareInputTextOptions.NORMALIZE) != 0)
         prepped = prepped.normalize(-1, NormalizeMode.NFC);
     
@@ -255,7 +255,7 @@ public string to_hex_string(string str) {
 
 // A note on the collated_* and precollated_* methods:
 //
-// A bug report (http://trac.yorba.org/ticket/3152) indicated that two different Hirigana characters
+// A bug report (https://bugzilla.gnome.org/show_bug.cgi?id=717135) indicated that two different Hirigana 
characters
 // as Tag names would trigger an assertion.  Investigation showed that the characters' collation
 // keys computed as equal when the locale was set to anything but the default locale (C) or
 // Japanese.  A related bug was that another hash table was using str_equal, which does not use
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]