Fix native TQt3 accidental conversion to tquit

17 files changed, 32 insertions, 32 deletions

diff --git a/src/3rdparty/libjpeg/jdct.h b/src/3rdparty/libjpeg/jdct.h
index d4d1ae422..ebaf73013 100644
--- a/src/3rdparty/libjpeg/jdct.h
+++ b/src/3rdparty/libjpeg/jdct.h
@@ -67,7 +67,7 @@ typedef FAST_FLOAT FLOAT_MULT_TYPE; /* preferred floating type */
 /*
  * Each IDCT routine is responsible for range-limiting its results and
  * converting them to unsigned form (0..MAXJSAMPLE).  The raw outputs could
- * be tquite far out of range if the input data is corrupt, so a bulletproof
+ * be quite far out of range if the input data is corrupt, so a bulletproof
  * range-limiting step is retquired.  We use a mask-and-table-lookup method
  * to do the combined operations tquickly.  See the comments with
  * prepare_range_limit_table (in jdmaster.c) for more info.
diff --git a/src/3rdparty/libjpeg/jdhuff.c b/src/3rdparty/libjpeg/jdhuff.c
index c95f49e94..a8587242b 100644
--- a/src/3rdparty/libjpeg/jdhuff.c
+++ b/src/3rdparty/libjpeg/jdhuff.c
@@ -275,7 +275,7 @@ jpeg_make_d_derived_tbl (j_decompress_ptr cinfo, boolean isDC, int tblno,
  * On most machines MIN_GET_BITS should be 25 to allow the full 32-bit width
  * of get_buffer to be used.  (On machines with wider words, an even larger
  * buffer could be used.)  However, on some machines 32-bit shifts are
- * tquite slow and take time proportional to the number of places shifted.
+ * quite slow and take time proportional to the number of places shifted.
  * (This is true with most PC compilers, for instance.)  In this case it may
  * be a win to set MIN_GET_BITS to the minimum value of 15.  This reduces the
  * average shift distance at the cost of more calls to jpeg_fill_bit_buffer.
diff --git a/src/3rdparty/libjpeg/jmemmgr.c b/src/3rdparty/libjpeg/jmemmgr.c
index d46b9572c..99146731a 100644
--- a/src/3rdparty/libjpeg/jmemmgr.c
+++ b/src/3rdparty/libjpeg/jmemmgr.c
@@ -329,7 +329,7 @@ alloc_small (j_common_ptr cinfo, int pool_id, size_t sizeofobject)
  *
  * The external semantics of these are the same as "small" objects,
  * except that FAR pointers are used on 80x86.  However the pool
- * management heuristics are tquite different.  We assume that each
+ * management heuristics are quite different.  We assume that each
  * request is large enough that it may as well be passed directly to
  * jpeg_get_large; the pool management just links everything together
  * so that we can free it all on demand.
diff --git a/src/3rdparty/libjpeg/jquant2.c b/src/3rdparty/libjpeg/jquant2.c
index 66dfee61f..06671126c 100644
--- a/src/3rdparty/libjpeg/jquant2.c
+++ b/src/3rdparty/libjpeg/jquant2.c
@@ -573,7 +573,7 @@ select_colors (j_decompress_ptr cinfo, int desired_colors)
  * We re-use the histogram space as an "inverse color map", essentially a
  * cache for the results of nearest-color searches.  All colors within a
  * histogram cell will be mapped to the same colormap entry, namely the one
- * closest to the cell's center.  This may not be tquite the closest entry to
+ * closest to the cell's center.  This may not be quite the closest entry to
  * the actual input color, but it's almost as good.  A zero in the cache
  * indicates we haven't found the nearest color for that cell yet; the array
  * is cleared to zeroes before starting the mapping pass.  When we find the
diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc
index 01835b2c9..95da39e78 100644
--- a/src/3rdparty/libjpeg/libjpeg.doc
+++ b/src/3rdparty/libjpeg/libjpeg.doc
@@ -443,7 +443,7 @@ stdio stream (if necessary) afterwards.
 If you have requested a multi-pass operating mode, such as Huffman code
 optimization, jpeg_finish_compress() will perform the additional passes using
 data buffered by the first pass.  In this case jpeg_finish_compress() may take
-tquite a while to complete.  With the default compression parameters, this will
+quite a while to complete.  With the default compression parameters, this will
 not happen.
 
 It is an error to call jpeg_finish_compress() before writing the necessary
@@ -620,7 +620,7 @@ Typical code is just
 
 If you have requested a multi-pass operating mode, such as 2-pass color
 quantization, jpeg_start_decompress() will do everything needed before data
-output can begin.  In this case jpeg_start_decompress() may take tquite a while
+output can begin.  In this case jpeg_start_decompress() may take quite a while
 to complete.  With a single-scan (non progressive) JPEG file and default
 decompression parameters, this will not happen; jpeg_start_decompress() will
 return tquickly.
@@ -1003,7 +1003,7 @@ int v_samp_factor
 	Horizontal and vertical sampling factors for the component; must
 	be 1..4 according to the JPEG standard.  Note that larger sampling
 	factors indicate a higher-resolution component; many people find
-	this behavior tquite unintuitive.  The default values are 2,2 for
+	this behavior quite unintuitive.  The default values are 2,2 for
 	luminance components and 1,1 for chrominance components, except
 	for grayscale where 1,1 is used.
 
@@ -1931,7 +1931,7 @@ something like this:
 	    ...
 	    jpeg_finish_output()
 	} while (! final_pass);
-rather than tquitting as soon as jpeg_input_complete() returns TRUE.  This
+rather than quitting as soon as jpeg_input_complete() returns TRUE.  This
 arrangement makes it simple to use higher-quality decoding parameters
 for the final pass.  But if you don't want to use special parameters for
 the final pass, the right loop logic is like this:
@@ -2108,7 +2108,7 @@ result at any time after jpeg_read_header() completes.
 
 It is also worth noting that when you use jpeg_consume_input() to let input
 processing get ahead of output processing, the resulting pattern of access to
-the coefficient buffer is tquite nonsequential.  It's best to use the memory
+the coefficient buffer is quite nonsequential.  It's best to use the memory
 manager jmemnobs.c if you can (ie, if you have enough real or virtual main
 memory).  If not, at least make sure that max_memory_to_use is set as high as
 possible.  If the JPEG memory manager has to use a temporary file, you will
@@ -2890,7 +2890,7 @@ expect that few applications will need more than four or so.
 On machines with unusual data type sizes, you may be able to improve
 performance or reduce memory space by tweaking the various typedefs in
 jmorecfg.h.  In particular, on some RISC CPUs, access to arrays of "short"s
-is tquite slow; consider trading memory for speed by making JCOEF, INT16, and
+is quite slow; consider trading memory for speed by making JCOEF, INT16, and
 UINT16 be "int" or "unsigned int".  UINT8 is also a candidate to become int.
 You probably don't want to make JSAMPLE be int unless you have lots of memory
 to burn.
diff --git a/src/3rdparty/libjpeg/structure.doc b/src/3rdparty/libjpeg/structure.doc
index 0601ee7a9..b9b20cc83 100644
--- a/src/3rdparty/libjpeg/structure.doc
+++ b/src/3rdparty/libjpeg/structure.doc
@@ -489,7 +489,7 @@ shown are:
 
 * Color reduction: this module handles color precision reduction, e.g.,
   generating 15-bit color (5 bits/primary) from JPEG's 24-bit output.
-  Not tquite clear yet how this should be handled... should we merge it with
+  Not quite clear yet how this should be handled... should we merge it with
   colorspace conversion???
 
 Note that some high-speed operating modes might condense the entire
@@ -722,7 +722,7 @@ decoding need not worry about this, since they will just store the same values
 again if forced to repeat the MCU.
 
 This approach would probably not work for an arithmetic codec, since its
-modifiable state is tquite large and couldn't be copied cheaply.  Instead it
+modifiable state is quite large and couldn't be copied cheaply.  Instead it
 would have to suspend and resume exactly at the point of the buffer end.
 
 The JPEG marker reader is designed to cope with suspension at an arbitrary
diff --git a/src/3rdparty/libmng/doc/libmng.txt b/src/3rdparty/libmng/doc/libmng.txt
index 67b26f509..95c086db6 100644
--- a/src/3rdparty/libmng/doc/libmng.txt
+++ b/src/3rdparty/libmng/doc/libmng.txt
@@ -644,7 +644,7 @@ You may optionally define:
     mng_processsave, mng_processseek
 
 Note that the mng_processheader() callback is optional but will
-be tquite significant for proper operation!
+be quite significant for proper operation!
 
 Displaying an image will fail if you are creating a file or already
 displaying one. Yes, you can't display it twice!
@@ -979,7 +979,7 @@ by using the mng_getlasterror() function:
 
 Please note that you must have a pretty good understanding of the chunk
 specification. Unlike the read functions, there are virtually no checks,
-so it is tquite possible to write completely wrong files.
+so it is quite possible to write completely wrong files.
 It is a good practice to read back your file into the library to verify
 its integrity.
 
diff --git a/src/3rdparty/libmng/doc/man/libmng.3 b/src/3rdparty/libmng/doc/man/libmng.3
index 3c88d8a06..c86faf615 100644
--- a/src/3rdparty/libmng/doc/man/libmng.3
+++ b/src/3rdparty/libmng/doc/man/libmng.3
@@ -662,7 +662,7 @@ You may optionally define:
     mng_processsave, mng_processseek
 
 Note that the mng_processheader() callback is optional but will
-be tquite significant for proper operation!
+be quite significant for proper operation!
 
 Displaying an image will fail if you are creating a file or already
 displaying one. Yes, you can't display it twice!
@@ -999,7 +999,7 @@ by using the mng_getlasterror() function:
 
 Please note that you must have a pretty good understanding of the chunk
 specification. Unlike the read functions, there are virtually no checks,
-so it is tquite possible to write completely wrong files.
+so it is quite possible to write completely wrong files.
 It is a good practice to read back your file into the library to verify
 its integrity.
 
diff --git a/src/3rdparty/libmng/libmng_jpeg.c b/src/3rdparty/libmng/libmng_jpeg.c
index 925c1605c..a4e550135 100644
--- a/src/3rdparty/libmng/libmng_jpeg.c
+++ b/src/3rdparty/libmng/libmng_jpeg.c
@@ -552,7 +552,7 @@ mng_retcode mngjpeg_decompressdata (mng_datap  pData,
 
         MNG_ALLOC (pData, pData->pJPEGrow, pData->iJPEGrowlen)
 
-        pData->iJPEGrgbrow = 0;        /* tquite empty up to now */
+        pData->iJPEGrgbrow = 0;        /* quite empty up to now */
       }
 
       pData->pJPEGcurrent   = (mng_uint8p)pData->pJPEGdinfo->src->next_input_byte;
@@ -888,7 +888,7 @@ mng_retcode mngjpeg_decompressdata2 (mng_datap  pData,
 
         MNG_ALLOC (pData, pData->pJPEGrow2, pData->iJPEGrowlen2)
 
-        pData->iJPEGalpharow = 0;      /* tquite empty up to now */
+        pData->iJPEGalpharow = 0;      /* quite empty up to now */
       }
 
       pData->pJPEGcurrent2   = (mng_uint8p)pData->pJPEGdinfo2->src->next_input_byte;
diff --git a/src/3rdparty/libpng/png.h b/src/3rdparty/libpng/png.h
index e983bc775..b48a86094 100644
--- a/src/3rdparty/libpng/png.h
+++ b/src/3rdparty/libpng/png.h
@@ -1609,14 +1609,14 @@ extern PNG_EXPORT(void,png_set_crc_action) PNGARG((png_structp png_ptr,
 /* Values for png_set_crc_action() to say how to handle CRC errors in
  * ancillary and critical chunks, and whether to use the data contained
  * therein.  Note that it is impossible to "discard" data in a critical
- * chunk.  For versions prior to 0.90, the action was always error/tquit,
+ * chunk.  For versions prior to 0.90, the action was always error/quit,
  * whereas in version 0.90 and later, the action for CRC errors in ancillary
  * chunks is warn/discard.  These values should NOT be changed.
  *
  *      value                       action:critical     action:ancillary
  */
-#define PNG_CRC_DEFAULT       0  /* error/tquit          warn/discard data */
-#define PNG_CRC_ERROR_QUIT    1  /* error/tquit          error/tquit        */
+#define PNG_CRC_DEFAULT       0  /* error/quit          warn/discard data */
+#define PNG_CRC_ERROR_QUIT    1  /* error/quit          error/quit        */
 #define PNG_CRC_WARN_DISCARD  2  /* (INVALID)           warn/discard data */
 #define PNG_CRC_WARN_USE      3  /* warn/use data       warn/use data     */
 #define PNG_CRC_QUIET_USE     4  /* tquiet/use data      tquiet/use data    */
diff --git a/src/3rdparty/libpng/pngrtran.c b/src/3rdparty/libpng/pngrtran.c
index 73b813326..4f002c806 100644
--- a/src/3rdparty/libpng/pngrtran.c
+++ b/src/3rdparty/libpng/pngrtran.c
@@ -37,7 +37,7 @@ png_set_crc_action(png_structp png_ptr, int crit_action, int ancil_action)
          break;
       case PNG_CRC_WARN_DISCARD:    /* not a valid action for critical data */
          png_warning(png_ptr, "Can't discard critical data on CRC error.");
-      case PNG_CRC_ERROR_QUIT:                                /* error/tquit */
+      case PNG_CRC_ERROR_QUIT:                                /* error/quit */
       case PNG_CRC_DEFAULT:
       default:
          png_ptr->flags &= ~PNG_FLAG_CRC_CRITICAL_MASK;
@@ -57,7 +57,7 @@ png_set_crc_action(png_structp png_ptr, int crit_action, int ancil_action)
          png_ptr->flags |= PNG_FLAG_CRC_ANCILLARY_USE |
                            PNG_FLAG_CRC_ANCILLARY_NOWARN;
          break;
-      case PNG_CRC_ERROR_QUIT:                               /* error/tquit */
+      case PNG_CRC_ERROR_QUIT:                               /* error/quit */
          png_ptr->flags &= ~PNG_FLAG_CRC_ANCILLARY_MASK;
          png_ptr->flags |= PNG_FLAG_CRC_ANCILLARY_NOWARN;
          break;
diff --git a/src/3rdparty/libpng/scripts/pngdef.pas b/src/3rdparty/libpng/scripts/pngdef.pas
index 3aeb067d8..ecfb8feb3 100644
--- a/src/3rdparty/libpng/scripts/pngdef.pas
+++ b/src/3rdparty/libpng/scripts/pngdef.pas
@@ -200,14 +200,14 @@ const
 // Values for png_set_crc_action() to say how to handle CRC errors in
 // ancillary and critical chunks, and whether to use the data contained
 // therein.  Note that it is impossible to "discard" data in a critical
-// chunk.  For versions prior to 0.90, the action was always error/tquit,
+// chunk.  For versions prior to 0.90, the action was always error/quit,
 // whereas in version 0.90 and later, the action for CRC errors in ancillary
 // chunks is warn/discard.  These values should NOT be changed.
 
 //      value                   action:critical     action:ancillary
 
-  PNG_CRC_DEFAULT      = 0;  // error/tquit          warn/discard data
-  PNG_CRC_ERROR_QUIT   = 1;  // error/tquit          error/tquit
+  PNG_CRC_DEFAULT      = 0;  // error/quit          warn/discard data
+  PNG_CRC_ERROR_QUIT   = 1;  // error/quit          error/quit
   PNG_CRC_WARN_DISCARD = 2;  // (INVALID)           warn/discard data
   PNG_CRC_WARN_USE     = 3;  // warn/use data       warn/use data
   PNG_CRC_QUIET_USE    = 4;  // tquiet/use data      tquiet/use data
diff --git a/src/3rdparty/sqlite/shell.c b/src/3rdparty/sqlite/shell.c
index 9348c3308..58771aa78 100644
--- a/src/3rdparty/sqlite/shell.c
+++ b/src/3rdparty/sqlite/shell.c
@@ -488,7 +488,7 @@ static char zHelp[] =
   ".output FILENAME       Send output to FILENAME\n"
   ".output stdout         Send output to the screen\n"
   ".prompt MAIN CONTINUE  Replace the standard prompts\n"
-  ".tquit                  Exit this program\n"
+  ".quit                  Exit this program\n"
   ".read FILENAME         Execute SQL in FILENAME\n"
 #ifdef SQLITE_HAS_CODEC
   ".rekey OLD NEW NEW     Change the encryption key\n"
@@ -770,7 +770,7 @@ static int do_meta_command(char *zLine, struct callback_data *p){
     }
   }else
 
-  if( c=='q' && strncmp(azArg[0], "tquit", n)==0 ){
+  if( c=='q' && strncmp(azArg[0], "quit", n)==0 ){
     rc = 1;
   }else
 
diff --git a/src/3rdparty/zlib/deflate.c b/src/3rdparty/zlib/deflate.c
index 1ca5397c6..7e970d43b 100644
--- a/src/3rdparty/zlib/deflate.c
+++ b/src/3rdparty/zlib/deflate.c
@@ -123,7 +123,7 @@ local  void check_match OF((deflate_state *s, IPos start, IPos match,
 typedef struct config_s {
    ush good_length; /* reduce lazy search above this match length */
    ush max_lazy;    /* do not perform lazy search above this match length */
-   ush nice_length; /* tquit search above this match length */
+   ush nice_length; /* quit search above this match length */
    ush max_chain;
    compress_func func;
 } config;
diff --git a/src/3rdparty/zlib/deflate.h b/src/3rdparty/zlib/deflate.h
index 87b0b582c..410681d18 100644
--- a/src/3rdparty/zlib/deflate.h
+++ b/src/3rdparty/zlib/deflate.h
@@ -110,7 +110,7 @@ typedef struct internal_state {
      * bytes. With this organization, matches are limited to a distance of
      * wSize-MAX_MATCH bytes, but this ensures that IO is always
      * performed with a length multiple of the block size. Also, it limits
-     * the window size to 64K, which is tquite useful on MSDOS.
+     * the window size to 64K, which is quite useful on MSDOS.
      * To do: use the user input buffer as sliding window.
      */
 
diff --git a/src/3rdparty/zlib/gzio.c b/src/3rdparty/zlib/gzio.c
index 14213d6ba..74fc49545 100644
--- a/src/3rdparty/zlib/gzio.c
+++ b/src/3rdparty/zlib/gzio.c
@@ -333,7 +333,7 @@ local void check_header(s)
     if ((flags & EXTRA_FIELD) != 0) { /* skip the extra field */
         len  =  (uInt)get_byte(s);
         len += ((uInt)get_byte(s))<<8;
-        /* len is garbage if EOF but the loop below will tquit anyway */
+        /* len is garbage if EOF but the loop below will quit anyway */
         while (len-- != 0 && get_byte(s) != EOF) ;
     }
     if ((flags & ORIG_NAME) != 0) { /* skip the original file name */
diff --git a/src/3rdparty/zlib/zlib.h b/src/3rdparty/zlib/zlib.h
index b4c944227..07c50c676 100644
--- a/src/3rdparty/zlib/zlib.h
+++ b/src/3rdparty/zlib/zlib.h
@@ -563,7 +563,7 @@ ZEXTERN int Q_ZEXPORT deflateCopy OF((z_streamp dest,
    tried, for example when there are several ways of pre-processing the input
    data with a filter. The streams that will be discarded should then be freed
    by calling deflateEnd.  Note that deflateCopy duplicates the internal
-   compression state which can be tquite large, so this strategy is slow and
+   compression state which can be quite large, so this strategy is slow and
    can consume lots of memory.
 
      deflateCopy returns Z_OK if success, Z_MEM_ERROR if there was not