Oleg:
        Hello! Feedback below:

> As work with CVS proved not to be as easy as I had thought, I will use
> Igor's channel to check the my files in and out. So, do not be
> surprised to find my updates checked in by user Igor.

        No prob. His username in the CVS server is "intproj"
anyhow. :)


> I.
> I added an icon File Transfer service. Its bitmaps are ft.bmp and
> ft_sel.bmp. When open,
> the tabs appear: "Status", "Send a File..." and "Receive a file".

        It's a good start. I'll send you a mockup of what I would
prefer, and I'll check-in some new icons. Some quick feedback: please
change the icon name in the main GUI to "File Transfer" instead of
"FTR", and in the "Send a File..." machine list, please show only
the other Kaboodle machines on the LAN, not all of the machines.
Thanks!


> At the time being, I am busy
> with implementing the "Send a File..." functionality. When user presses
> the "Send File" button, a dialog pops up reading "Choose File to
> Transfer for *UserName*" (as described in the Specification). File
> size is displayed in KB. Q: do I have to consider one KB contain
> 1024 bytes (as commonly adopted) or 1000 (somebody likes this best)?

        1024 is correct for both kB and MB. Be careful though: it's
not UserName as much as it is MachineName or DeviceName.

> II.
> "Status" tab. The Spec says it should monitor ALL the File Transfer activity
> within the lan.
> The FT processes that the current machine is invoked in have "Cancel"
> buttons. This approach
> has the following issues:
> - Broadcasts are required to notify all the lan of initiation and progress
> of all the FT process,
> which, I am afraid, might substantially affect both the lan traffic and
> Kaboodle efficiency.
> - FT monitoring gui will look rather cumbersome: as user opened "Status" tab
> they see
> something like:
> 1 <FROM USER A> <TO USER B> <FILE_1> <progress bar..........     >
> ...
> m <FROM ME>     <TO USER C> <FILE_M> <progress bar.....          >  [CANCEL]
> n <FROM ME>     <TO USER D> <FILE_N> <progress bar.              >  [CANCEL]

        Yikes. You're right, that's too much. Definitely don't need
the task bar. So it'd look like:

1. MachineOne is transferring File_1 to you on this machine  [Cancel]
2. MachineTwo is transferring File_2 to MachineThree
3. You are transferring File_3 to MachineFour [Cancel]

        Note that there is no [Cancel] for transfer #2 there.

> My suggestion consists in the following. At the beginning stage, we
> implement monitoring of
> those files being transferred to and from the given machine only rather
> than the entire lan.

        Let me know what you think of the above before we go this
easier way.


> III.
> When I was inserting the File Transfer service icon, I came across some
> redundant code. Thus,
> functions:
> CEFIcon *AddVPN(CGUID id, CString name);
> CEFIcon *AddVNC(CGUID id, CString name);
> only differ in two integer constants. I had to add my own function
> CEFIcon *AddFT(CGUID id, CString name);
> which, if follow the logic suggested, would make me copy the function body
> once again. I
> chose not to do so but retrofit the original function so to eliminate the
> redundant code and
> provide feasible icon updates in future. My new function is
> CEFIcon* AddServiceIcon(CGUID id, const CString& rStrName, UINT uiBmp, UINT
> uiBmpSel);
> and all the three above functions now delegate the calls to that one:
> CEFIcon *AddVPN(CGUID id, CString name);
> CEFIcon *AddVNC(CGUID id, CString name);
> CEFIcon *AddFT(CGUID id, CString name);

        Good idea!

> The same issue was encountered in the classes:
> class CNIDVNCService : public CNIDService
> class CNIDVPNService : public CNIDService
> I moved the common functionality into the base class (which had already
> existed) and derived
> my own class
> class CNIDFTService : public CNIDService
> All the obsolete source code is left on in comments.

        Perfect, thanks.

> Enclosed is a sample gui written in MFC as stand-alone executable.

        I'll look at it soon...

-Scott



_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel

Reply via email to