Mailinglist Archive: zypp-devel (68 mails)

[Michael Andres <ma@xxxxxxx>]

zypp::ProgressData Example:

      #include <iostream>
      #include "zypp/base/Logger.h"
      #include "zypp/base/IOStream.h"
      #include "zypp/base/InputStream.h"
      #include "zypp/ProgressData.h"

      // Defined in ProgressData.h:
      // Initialize ProgressData from an InputStream.
      //
      // ProgressData makeProgressData( const InputStream & input_r )
      // {
      //  ProgressData ret;
      //  ret.name( input_r.name() );
      //  if ( input_r.size() > 0 )
      //    ret.range( input_r.size() );
      //  return ret;
      // }

      void simpleParser( const InputStream & input_r,
                         const ProgressData::ReceiverFnc & fnc_r = ProgressData::ReceiverFnc() )
      {
        ProgressData ticks( makeProgressData( input_r ) );
        ticks.sendTo( fnc_r );
        ticks.toMin(); // start sending min (0)

        iostr::EachLine line( input_r );
        for( ; line; line.next() )
        {
          /* process the line */

          if ( ! ticks.set( input_r.stream().tellg() ) )
            return; // user requested abort
        }

        ticks.toMax(); // take care 100% are reported on success
      }

      int main( int argc, char * argv[] )
      {
        simpleParser( "./packages" );
        simpleParser( "./packages.gz" );
        return ( 0 );
      }


That's a simple parser example with progress support.

- InputStream: This class wraps an istream. The input stream might be
a file (plain or gzipped) or stdin or some other data source. The user
should not care about how the stream was created. InputStream has a
name (arbitrary string, defaults to the filename if the stream is a file).
InputStream has a size (the file size for uncompressed files,
otherwise -1 i.e. unknown size). Those are the defaults but name and
size can be set to whatever value you like.

- makeProgressData: Convenience function to initialize ProgressData
from an InputStream. If the stream provides a size, progress is set
up to report percentage. If the stream size is unknown (<0), progress
is set up with an empty range. It will sent 'still alive' message.

- ticks.sendTo( fnc_r );: Connect ProgressData to an optional
receiver.

- ticks.toMin() / ticks.set(..) / ticks.toMax(): There are a few more
progress triggering methods. Common to all of them: they return a
boolean, indicating whether a callback recipient requests to abort
(true==continue, false==abort).


- Benefit for the parser (or other progress reporting actions): It's
IMO quite easy to setup and use. Keep in mind that not every progress
you report to ProgressData is actually sent to the recipient.

  simpleParser( "./packages" ); invoked with a 16 MB packages file
  sends a trigger for each line. But the UI receives only:

  22:50:39 {#1|./packages}(0%)
  22:50:39 {#1|./packages}(21%)
  22:50:39 {#1|./packages}(42%)
  22:50:40 {#1|./packages}(63%)
  22:50:40 {#1|./packages}(84%)
  22:50:40 {#1|./packages}(100%)

So do not try to 'optimize' by remembering the last value you sent,
comparing it to the corrent value, computing whatever....

Parsers (or other progress reporting actions) simply trigger.
Everything else is ProgressData's  job.

- See the ProgressData autodocs for some other example.


TODO: Communication between a ProgressData and the UI should be
improved. The current callbacks we use send a single value,
interpreted as percentage.

But it would be easy to indicate whether percentage or 'still alive'
trigges are sent. The ProgressData's name and id might be interesting
for a recipient as well (e.g. if one recipient want's to manage
multiple parallel downloads).

The progress reporting action could be easily enabled to indicate
whether it is willing and able to abort. The UI could use that hint
to dim or remove a cancel button.



But for now we should use ProgressData in new code. If we have some
spare time, we adapt the existing code.


-- 

cu,
    Michael Andres

+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862  27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres             YaST Development            ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF:  Markus Rex,  HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+

-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx