i seem to be very bad at explaining myself. :( maybe ye think i have some problem to be solved when i am just asking if what i am doing is the "correct Do way". If what i am doing is the best way, I then suggest what i think is a better way to do it.
I think from you and Alex's responces i can summarise that i was thinking about things in the wrong way. let me try and answer your direct questions first then try restate my question. >Niall, you want to implement the Do.Universe.IFileItem interface. thats what im doing at the moment. see http://pastebin.com/m6d68f59f I am unhappy about this because i am copying and pasting code from FileItem. I have an idea about how to make a general instance of FileItem that people can extend and which will call down to platform specific code when needed. some answers to your questions: > Niall, is your main problem that you want a function: > string IconForFile (IFileItem) No. i am totally happy with the existing Icon function. > ? What kind of files are you representing? PDF, PS, DJVU, etc. In this regard BibtexItem is probably a bad name, should be "DocumentItem" > I was under the impression that they were all tex or bib files, and you could > just assign icons > from a fixed set. Do you need to potentially represent many types of > files? i want thumbnails of the files as _exactly_ as the FileItem.Icon function provides. > In this case, I would use Services.UniverseFactory.NewFileItem > (string path) to create abstract file items instead of creating your > own IFileItem subtype. Is there any reason you need your own IFileItem > subtype? I want to set the Text and Description based on the contents of a bibtex file. What i want: A FileItem whose Text, Description and Path are customised by me. i just felt it was a bit strange to be copying and pasting code from the FileItem class because i wanted it to behave exactly the same way as that class for one method. I also wanted the plugin code be platform independent. if that is the way to do it in Do, thats fine, i just thought their might be a better way to do it. i may try in a few weeks to make a proof of concept implementation of a platform independent FileItem that can be extended. thanks and sorry for distracting ye from actual Do work. and thanks for your patience. Niall On Wed, Jan 21, 2009 at 7:28 PM, David Siegel <[email protected]> wrote: > > Niall, is your main problem that you want a function: > > string IconForFile (IFileItem) > > ? What kind of files are you representing? I was under the impression > that they were all tex or bib files, and you could just assign icons > from a fixed set. Do you need to potentially represent many types of > files? In this case, I would use Services.UniverseFactory.NewFileItem > (string path) to create abstract file items instead of creating your > own IFileItem subtype. Is there any reason you need your own IFileItem > subtype? > > David > > On Wed, Jan 21, 2009 at 10:21 AM, David Siegel <[email protected]> wrote: >> Niall, you want to implement the Do.Universe.IFileItem interface. >> >> interface IItem { >> string Name { get; } >> string Description { get; } >> string Icon { get; } >> } >> >> interface IUriItem : IItem { >> string Uri { get; } >> } >> >> interface IFileItem : IUriItem { >> string Path { get; } >> } >> >> >> Your custom Item class needs to implement IFileItem. All you need to >> do is provide a Path (and a Uri), along with Name, Description, and >> Icon, and you will have something that acts like a file within Do. So, >> what exactly is the confusion? >> >> David >> >> >> On Wed, Jan 21, 2009 at 8:40 AM, Niall Murphy <[email protected]> wrote: >>> >>>>> In short. i want to extend FileItem. >>>>> I cant find the assembly that will let me extend from fileItem. can >>>>> you tell me what it is called? >>>> FileItem lives in Do.Universe.Linux. >>> >>> The type or namespace name `FileItem' does not exist in the namespace >>> `Do.Universe.Linux'. Are you missing an assembly reference?(CS0234) >>> >>> I have included all references Do.* which for me are >>> Do.Interface.Linux >>> Do.Platform >>> Do.Platform.Linux >>> Do.Universe >>> >>> Is there something i am missing or not understanding? >>> >>>>> now a design question. >>>>> If i can extend from Do.Platform.Linux/src/Do.Universe/FileItem.cs it >>>>> would seem wrong that i am extending from platform specific class. >>>>> Do you think it is possible or a good idea to have a FileItem in >>>>> Do.Platfrom.Common that would be generic but on different systems use >>>>> the specific implementation from another class? >>>> >>>> Files are different on different platforms, the Do FileItem in >>>> Universe.Linux uses some linuxisms, which is why it's in Universe.Linux. >>>> This is the point of IFileItem, to provide a crossplatform abstraction >>>> layer >>>> that is safe to refererence. >>> >>> yes i understand, I am suggesting a new class that might make things >>> cleaner for you and for plugin developers. >>> i think i remember (i havnt touched eclipse plugins for about 3 years) >>> eclipse having a system where there was an class >>> File that anyone could use and simply called out to the appropriate >>> platform dependant other classes. >>> >>> So Do.Universe.FileItem would have code along the lines of >>> >>> class Do.Universe.FileItem extends Item implements Iopenable >>> function Icon () : >>> if System.platform = Gnome : >>> return Do.Platform.Linux.FileItem.Icon () >>> if System.platform = Windows >>> return Do.Platform.Windows.FileItem.Icon () >>> else return "icons.generic_icon.svg" >>> >>> There are probably better ways to implement it (without nasty static >>> methods etc) but thats what i have in mind. >>> This way plugin devs can have platform independent code, not have to >>> copy and paste code and still have cool features like thumbnail icons. >>> >>> Niall >>> >>>> >>>> >>>> -- >>>> --Alex Launi >>>> >>>> > >>>> >>> >>> >> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GNOME Do" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/gnome-do?hl=en -~----------~----~----~----~------~----~------~--~---
