that answers my question I _knew_ there was a better way!
I didnt think of using the NewFileItem factory in that way. thanks david and hanks again for your patience. On Wed, Jan 21, 2009 at 8:06 PM, David Siegel <[email protected]> wrote: > > Everything you are doing looks fine, except the Icon code. > > string GetFileIcon (string path) > { > return Services.UniverseFactory.NewFileItem (path).Icon; > } > > Use this function to get platform-specific file thumbnails on all > platforms. Make sure you cache the string returned in an instance > field, because that call is not super inexpensive. > > David > > > On Wed, Jan 21, 2009 at 10:59 AM, Niall Murphy <[email protected]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
