Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #739 > unrolled thread

Will there be a CiderXPress?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Will there be a CiderXPress? markpmlim@yahoo.com.sg - 2013-07-11 20:22 -0700
    Re: Will there be a CiderXPress? Hugh Hood <hughhood@earthlink.net> - 2013-07-13 13:09 -0500
      Re: Will there be a CiderXPress? Mark P M Lim <marklim@macgui.com> - 2013-07-14 09:42 +0000
        Re: Will there be a CiderXPress? Mark P M Lim <marklim@macgui.com> - 2013-08-02 02:44 +0000
          Re: Will there be a CiderXPress? Alex Lee <alelee@mac.com> - 2013-08-02 16:45 +1000
            Re: Will there be a CiderXPress? Mark P M Lim <marklim@macgui.com> - 2013-08-18 03:25 +0000
              Re: Will there be a CiderXPress? "Bill Buckels" <bbuckels@mts.net> - 2013-08-19 07:48 -0500
              Re: Will there be a CiderXPress? Alex Lee <alelee@mac.com> - 2014-02-08 15:38 +1100

#739 — Will there be a CiderXPress?

Hi to all,

Since my lasting posting months back on the use of CiderPress' DiskImg library, I decided to explore the practicality of using its classes via a MacOSX GUI program. Starting from almost zero knowledge of Cocoa Programming, I managed (thanks to the power of the Internet) to "cobble" a program that implements a sub-class of NSOutlineView with Drag and Drop (DnD) capability. The most difficult part was coming up with code which implement a UI which would be similar to that of the MacOSX Finder.

Honestly speaking, after writing the program, I still have a hazy idea of Cocoa Programming concepts. And my understanding of CiderPress' DiskImg classes is not much better. Probably this is due to an inability to perform a paradigm shift after spending years on procedural programming.

The program I have written doesn't have the functionalities of the original. It only utilizes a subset of CiderPress' DiskImg classes and only deals with uncompressed disk images (.2mg, .po, .do, .img & .hdv). It 

The program does two things well. It allows DnD of files and folders to/from Finder and intra/inter-document DnD. In particular, IIGS resource forks are preserved when files are dragged to Finder. The use of an OutlineView lends itself well to the display hierarchical data that can be expanded and collapsed, in file systems like ProDOS and HFS.

The program code is messy and I still can't replicate certain aspects of Finder's ease of use. Memory management leaves a lot to be desired and accessing the files/folders in the disk images is not optimized. For example, whenever I need to access a file/folder, I play safe using this code snippet: 

	DiskImg *pDiskImg = (DiskImg *)diskImgObject.cppDiskImg;
	DiskFS* pDiskFS = pDiskImg->OpenAppropriateDiskFS();
	DIError dierr = pDiskFS->Initialize(pDiskImg, DiskFS::kInitFull);

	// Convert path to a null-terminated ascii string
	NSArray *components = [pathToFile componentsSeparatedByString: @"/"];
	NSString *tmpString = [components componentsJoinedByString: @ ":"];
	const char *cstr = [tmpString StringUsingEncoding:NSASCIIStringEncoding];
	A2File *pFile = pDiskFS->GetFileByName(cstr);

Imagine copying hundreds/thousands of files consisting of tens of MBytes of data.

Perhaps a more experienced MacOSX programmer will have a better shot. In the meantime, I am re-learning Cocoa Programming to get clearer idea of its concepts. The cocoa docs are written by experts for experts; I am not one of them. BTW, there is a program called exlibris (with source) on the internet

https://github.com/dcsch/exlibris

I had borrowed a number of ideas from it.

Regards.

Mark

[toc] | [next] | [standalone]

#740

Mark:

I think you've got the makings of a fine project, and hope that you continue
to tweak it.

Having just finished up beta testing my first 'real' Cocoa project (a
Spotlight Importer for AppleWorks AWP files) I can second the 'power of the
Internet' you referenced as a vital learning tool. In my younger (read more
patient) days, I probably could have sit down with a 700-page text on Cocoa
and devoured it cover to cover, but I'm no longer that guy. Heck, I should
give the guys on stackoverflow half the credit for my importer, and I never
even had to ask a question!  Many others had previously gone down the same
or similar paths, and the answers poured forth. Maybe your experience is
similar to mine, or maybe not.

Anyway, as you continue on (CiderXPress does have a nice sound to it), I
would ask that you consider preserving (since this is on Mac OS X) the
ProDOS file attributes via the tried-and-true Finder attributes of Creator
Code and FileType. I know, I know that the Creator Code is deprecated, but
it's still available. FileType allows ProDOS File Type and Aux Type to be
preserved, and is preferable, I think, to file extensions or xattrs.

Sherlock did that (Creator Code/FileType) with ShrinkFitX and it's just
swell.

Keep us updated.






Hugh Hood



in article cc6c32fc-2760-45d5-a358-c0619de3894a@googlegroups.com,
markpmlim@yahoo.com.sg at markpmlim@yahoo.com.sg wrote on 7/11/13 10:22 PM:

> Hi to all,
> 
> Since my lasting posting months back on the use of CiderPress' DiskImg
> library, I decided to explore the practicality of using its classes via a
> MacOSX GUI program. Starting from almost zero knowledge of Cocoa Programming,
> I managed (thanks to the power of the Internet) to "cobble" a program that
> implements a sub-class of NSOutlineView with Drag and Drop (DnD) capability.
> The most difficult part was coming up with code which implement a UI which
> would be similar to that of the MacOSX Finder.
> 
> Honestly speaking, after writing the program, I still have a hazy idea of
> Cocoa Programming concepts. And my understanding of CiderPress' DiskImg
> classes is not much better. Probably this is due to an inability to perform a
> paradigm shift after spending years on procedural programming.
> 
> The program I have written doesn't have the functionalities of the original.
> It only utilizes a subset of CiderPress' DiskImg classes and only deals w
> ith uncompressed disk images (.2mg, .po, .do, .img & .hdv). It
> 
> The program does two things well. It allows DnD of files and folders to/from
> Finder and intra/inter-document DnD. In particular, IIGS resource forks are
> preserved when files are dragged to Finder. The use of an OutlineView lends
> itself well to the display hierarchical data that can be expanded and
> collapsed, in file systems like ProDOS and HFS.
> 
> The program code is messy and I still can't replicate certain aspects of
> Finder's ease of use. Memory management leaves a lot to be desired and
> accessing the files/folders in the disk images is not optimized. For example,
> whenever I need to access a file/folder, I play safe using this code snippet:
> 
> DiskImg *pDiskImg = (DiskImg *)diskImgObject.cppDiskImg;
> DiskFS* pDiskFS = pDiskImg->OpenAppropriateDiskFS();
> DIError dierr = pDiskFS->Initialize(pDiskImg, DiskFS::kInitFull);
> 
> // Convert path to a null-terminated ascii string
> NSArray *components = [pathToFile componentsSeparatedByString: @"/"];
> NSString *tmpString = [components componentsJoinedByString: @ ":"];
> const char *cstr = [tmpString StringUsingEncoding:NSASCIIStringEncoding];
> A2File *pFile = pDiskFS->GetFileByName(cstr);
> 
> Imagine copying hundreds/thousands of files consisting of tens of MBytes of
> data.
> 
> Perhaps a more experienced MacOSX programmer will have a better shot. In the
> meantime, I am re-learning Cocoa Programming to get clearer idea of its
> concepts. The cocoa docs are written by experts for experts; I am not one of
> them. BTW, there is a program called exlibris (with source) on the internet
> 
> https://github.com/dcsch/exlibris
> 
> I had borrowed a number of ideas from it.
> 
> Regards.
> 
> Mark

[toc] | [prev] | [next] | [standalone]

#742

Hugh Hood wrote:
> Mark:
> 
> I think you've got the makings of a fine project, and hope that you
> continue
> to tweak it.
>

Thanks, Hugh for the encouragement. The program as-is does not do justice to
Andy McFadden's work.

>
> Anyway, as you continue on (CiderXPress does have a nice sound to it), I
> would ask that you consider preserving (since this is on Mac OS X) the
> ProDOS file attributes via the tried-and-true Finder attributes of Creator
> Code and FileType. I know, I know that the Creator Code is deprecated, but
> it's still available. FileType allows ProDOS File Type and Aux Type to be
> preserved, and is preferable, I think, to file extensions or xattrs.
>

No problems preserving the ProDOS FileType and AuxType of files but I have
difficulty with the dates (creation & modification). CiderPress' source code
doesn't seem to have a separate method for changing the dates.

Regards.

Mark
PS. Can't seem to reply through Google.

[toc] | [prev] | [next] | [standalone]

#782

Hi everyone,

A few tweaks were made to the program since my last post. Here's a snapshot
of an HFS disk image I made for demonstration purposes.

http://www.macgui.com/upload/gallery/f_4/user_4445/med/upload_2012.gif

The program was developed and  tested mainly with Xcode 3.2.6 running under
SnowLeopard.  Xcode 4.4 was also used to edit some of the .xib files and for
occasional testing purposes.

More tweaks especially one to simulate the MacOSX copy/replace confirmation
dialog are required.

Copy and Paste works but I can't seem to get the MacOSX Finder to display
its "Paste" menu item.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#783

On 2013-08-02 12:44:24 +1000, Mark P M Lim said:

> Hi everyone,
> 
> A few tweaks were made to the program since my last post. Here's a snapshot
> of an HFS disk image I made for demonstration purposes.
> 
> http://www.macgui.com/upload/gallery/f_4/user_4445/med/upload_2012.gif
> 
> The program was developed and  tested mainly with Xcode 3.2.6 running under
> SnowLeopard.  Xcode 4.4 was also used to edit some of the .xib files and for
> occasional testing purposes.
> 
> More tweaks especially one to simulate the MacOSX copy/replace confirmation
> dialog are required.
> 
> Copy and Paste works but I can't seem to get the MacOSX Finder to display
> its "Paste" menu item.
> 
> Regards.
> 
> Mark

I'm rootin' for ya!

- Alex
-- 
http://www.whatisthe2gs.apple2.org.za/

[toc] | [prev] | [next] | [standalone]

#801

Hi to all,

> I'm rootin' for ya!

Thanks, Alex.

Previously after a DnD, I re-built the entire tree structure of the
Outlineview widget by reading the data from the disk image. This ensures
that the pathname of a file stored as a field in a tree node corresponds
exactly to that on the disk image. The disadvantage is all nodes will
collapse visually; not a good user experience.

I decided the least that could be done is ensure the destination folder
remains expanded after a drop is accepted. I think I have met with some
success here.

To summarise, the program (so far) works with only uncompressed disk images;
its main features are

1) dragging and dropping of files/folders from/to a folder location managed
by Finder to/from an disk image (document),
2) intra-/inter-document drag and drop of files/folders,
3) deletion of files and folders from a disk image,
4) renaming of files and folders,
5) intra/inter-document copy and paste.

Copy and Paste from Finder is working but I have not found out how to get
Finder's main edit menu/contextual menu to enable its Paste menu item.

Thanks to all for taking an interest in this project. The main credit
belongs to Andy; CiderPress's C++ classes takes care of many things behind
the scene.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#802

"Mark P M Lim" <marklim@macgui.com> wrote:
> I decided the least that could be done is ensure the destination folder 
> remains expanded after a drop is accepted. I think I have met with some 
> success here.

That sounds very elegant. Also consider tagging groups of files for file 
type and aux type batch changes (like Apple II OASIS did). Stay with the 
ProDOS file type paradigm when pasting from a ProDOS disk to a DOS 3.3 disk 
but display the DOS 3.3 filetype in the DOS 3.3 drop-down menu as well as 
the ProDOS (CiderPress) filetype cross-reference. If you use file attribute 
preservation tags for import and export, stay with Andy's naming. Offer an 
Action Dialog option to extract disk sectors and blocks, and to keep the 
head and tail of a DOS 3.3 file when extracting to a hard disk.

CiderPress has good support for CF cards, and good support for CP/M 80 disks 
as well. An external configuration file for disk and media formats not 
currently supported, including file types and other attributes and behaviour 
would greatly extend the usefulness of any next generation version.

But I long ago realized that I couldn't do what he has done, let alone 
expand on it. Not in my lifetime so I admire your energy and ability.

> The main credit belongs to Andy; CiderPress's C++ classes takes care of 
> many things behind
the scene.

The Ciderpress source code has been inavluable as a learning tool to me. (So 
has the source code for AppleWin.)

Andy's comments in CiderPress are like attending an advanced school of Apple 
II history coupled with algorithm after algorithm with reasons attached. I 
sometimes imagine that if Andy could have cloned himself,  and written all 
that in longhand, the 30,000 or so pages of hard-cover books would take a 
whole shelf in a book-case and would cost more to print than the price of a 
Windows laptop computer today.

His classes are very elegant. Uncoupling them from the UI to port this 
cross-platform or even from VS-6 is yet another matter. Although I have even 
backported his SHR routines to 8 bit Aztec C65 (circa 1987) without any 
significant change and with-out problems.

I am grateful to Professor Andy too:) A very generous man!

Bill

[toc] | [prev] | [next] | [standalone]

#1152

On 2013-08-18 03:25:21 +0000, Mark P M Lim said:

> Hi to all,
> 
>> I'm rootin' for ya!
> 
> Thanks, Alex.
> 
> Previously after a DnD, I re-built the entire tree structure of the
> Outlineview widget by reading the data from the disk image. This ensures
> that the pathname of a file stored as a field in a tree node corresponds
> exactly to that on the disk image. The disadvantage is all nodes will
> collapse visually; not a good user experience.
> 
> I decided the least that could be done is ensure the destination folder
> remains expanded after a drop is accepted. I think I have met with some
> success here.
> 
> To summarise, the program (so far) works with only uncompressed disk images;
> its main features are
> 
> 1) dragging and dropping of files/folders from/to a folder location managed
> by Finder to/from an disk image (document),
> 2) intra-/inter-document drag and drop of files/folders,
> 3) deletion of files and folders from a disk image,
> 4) renaming of files and folders,
> 5) intra/inter-document copy and paste.
> 
> Copy and Paste from Finder is working but I have not found out how to get
> Finder's main edit menu/contextual menu to enable its Paste menu item.
> 
> Thanks to all for taking an interest in this project. The main credit
> belongs to Andy; CiderPress's C++ classes takes care of many things behind
> the scene.
> 
> Regards.
> 
> Mark

Hiya again Mark,

I just got your email and tried to reply, however I got the response 
that your email addy, marklim@macgui.com, doesn't exist. Have you got 
an alternative email address I could email you to?

- Alex
-- 
http://www.whatisthe2gs.apple2.org.za/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web