LCDInfo.com

So you say it is possible to check more than one E-Mail adress? If so can you give ma an example how you programmed it?

I don't see anyone saying that it's possible other than you... Are you sure you are reading Mingingbollock correctly?

_________________
Syridian,
http://syridian.com

Unitl a new system is built to give me a way to allow mutliple connections, only one is possible. I would be nice if LCD Info was reworked completely but that would involve a lot of work and most would not be mine.

KrAkKeN,

What's the issue with not being able to do multiple POP3's within the current LCDinfo?

P.S. Dude.. check your hotmail.

_________________
Syridian,
http://syridian.com

KrAkKeN,

how difficult would it be to include the (From) sender's address in your plugin?

_________________
My Plexeon-Insane LCD!-Or this one!-LCDinfo-LCDStudio

Please describe what is wrong in the current way and also some quick description of what kind changes should be done to the current plugin system to allow for the features you would like to have. I'm really interested of hearing your opinion as it can help making it better.

To be honest I don't really see what is preventing multiple accounts in the current system so it's even more necessary to know your thoughts.

coorz: Pretty hard now... I have lost my source for everything that I did on LCD Info which is a real bummer. I never released Build 19 source either...

Henri: I like how unique the system is and how much control you have I just don't like certain aspects. Thinking about it, the system is all there apart from a <plugindata> param that users can put data IN to the plugin (such as username and password). The things I speak of are just the general lack of a good editor. It makes it a chore to be able to display anything on screen.

I'm probably being very demanding and selfish here (sorry I don't mean to be) but what I would like is a complete re-design of the plugins and source so everything is properly modulised and all elements are encapsulated into their own "sections".

Not a great deal needs to be changed just a rewrite (following the code that is already there) and sorting everything out. The plugins need to all be re-written. No exceptions. To fit in with the new system.

The reason I say this is because so far, whenever new features are added to plugins, it's sort of a hack job and some are left cmpatible with only old versions and some with only new. If possible, it would be nice to add a streamlined way to add features to new plugins without destroying old compatibility.

This could work in a function table of about 32 entries. The software only has about 8 function calls at the moment and they could occupy the first 8 slots. Whenever a function is called, the table entry is called rathen than the function name (as long as it isn't null). That way new functions can be added without destroying the infrastructure.

I'm not 100% sure but I think I have had a quick look into the build 19 source so that would make me think that I have it somewhere. Maybe you emailed it to me or something. I'll check this.


Yes this is something that has been left out for a long time now even that I have planned to put it in. But adding it should be easy. Then the next thing to decide is what kind format should the parameter be. Just a text string ? That could probably be the most versatile solution. For some applications it can cause additional resource use if frequent parsing of the string is necessary but just one text string as parameter should be the simplest option.


You're correct here. Good editor is needed to make it easier to make screens. My plan has been that the core LCDInfo and gui/editor would be two separate pieces of software that would communicate with a well defined interface. I have added some functionality to the SDK interfaces to get started with this but there's still a lot to add. First I have wanted to make the core part good enough to know what kind features in the editor would be needed.


Don't worry about being too demanding. It's good to hear your thoughts and ideas of how things should work.

Yes I know the code would need some work to sort out everything to make it better structured. Any contributions here are welcome

Plugin compatibility with updated interfaces is a problem now but I don't think it should be that big problem when the interfaces get more mature. My idea was to keep changing the interfaces first to find out the good working solution and then freeze the particular interface when it seems to be working well and has the necessary features.

Wouldn't it be possible to structure the Plugins and the Core so that compatibility in the future wouldn't be an issue? Again, this is comming from someone who doesn't know too much about programming...

What are the compatibility issues at the moment? Is there a decent explaination somewhere about HOW the Core and the Plug-ins work? I have looked, but possibly NOT hard enough.

_________________
Syridian,
http://syridian.com

Future compatibility should not be an issue after the interfaces are decided to be mature enough and frozen. The reason that recently there have been changes that have broken compatibility is that I'm just working on what the interfaces should really be like. And because of this I'm not really sure if it would even be good to allow some plugins to use the old interfaces. At least that would make things more complicated.

And also even if in future there would be more interfaces coming the old plugins should not be affected as long as the old interfaces are not touched. Now if anyone has suggestions about how the current DataSource interface should be made better you can tell your opinions in the Developers forum for example. Hopefully this could be finalized pretty soon so that no changes would be required anymore.

I don't think there's really any explanation written about how the core and plugins work and interact. The source code is the best for seeing the details
Basically the plugins just tell the core what kind variables they offer and then the core asks the plugins for the variable values as it updates the screens. How all this happens is that the plugins implement some interfaces defined in the SDK and then LCDInfo asks the plugins what kind interfaces they offer. The interfaces include functions to communicate. For most current plugins offering data the most important interface is the "DataSource".
I'm not sure if this was what you were asking so if this didn't help you I'll try to make up something better
I don't think you were after the exact details of the core/plugin interaction as that can be quite hard for someone not knowing some C++. But if interested the source for this is in the plugin SDK (factory.h, component.h, api.h, etc...).

Hi there,

how often does the POP3-Plugin query the server? Is that time adjustable?

Sascha

It checks each <refresh> I believe. so I wouldn't go making it too quick if I were you.

_________________
Syridian,
http://syridian.com

doesn't work with gmail

Can you POP a Gmail account? I don't have Gmail, so I haven't played with it.

_________________
Syridian,
http://syridian.com

i can't connect, i think the prob is the port.
http://gmail.google.com/support/bin/answer.py?answer=13287