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
-~----------~----~----~----~------~----~------~--~---
