Miranda IM

Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: addon structure

  1. #21
    Join Date
    March 2005
    Location
    Germany, Duesseldorf
    Posts
    5,514
    my two cents about...

    Please look at the current addon site, how many "Requirements" you can find that are not true, only half-true, completely outdated or ...? And no, not all the pluigns with this wrong requirements are old.
    Someone ask for an example?
    http://addons.miranda-im.org/details...ewfile&id=2995
    http://addons.miranda-im.org/details...ewfile&id=3037 (only work on Windows NT/2000/XP/2003 ???)
    http://addons.miranda-im.org/details...ewfile&id=3694 (Requirement + Description=confusing)
    http://addons.miranda-im.org/details...ewfile&id=4036 (Where I can download Miranda 0.7???)
    This 4 plugins from the current 20 Top Downloads have ugly requirements=20% => About 3000 plugins overall = 600 plugins with ugly requirements. o_O
    If I assume that all this text come from an author, no offense, but no thanks if the authors should fill this fields.
    I don't know the reasons why 600 plugins have ugly requirements or dependencies, but don't tell me it's not true!
    And please don't tell me that everything will get better in the future!

    Volunteers?
    *YOU*, yes I mean YOU, would you do this? Can I see YOU in this team 2011? Would YOU install Clist_x and Message-Window_Y to see if a new plugin works?
    Be serious, someone have any good experience with volunteers here, especially if they MUST do something?

    Community?
    I think that's the only possible way, but I haven't any idea how.

    But on the other side, don't forget how important are correct requirements and "Not work with...", we can't await that any new user search around in the forum, the wiki or the IRC channel.
    Miranda stay and fails with correct working plugins.

  2. #22
    Join Date
    December 2006
    Location
    Germany/Munich
    Posts
    204
    Quote Originally Posted by Lastwebpage View Post
    my two cents about...

    Please look at the current addon site, how many "Requirements" you can find that are not true, only half-true, completely outdated or ...? And no, not all the pluigns with this wrong requirements are old.
    Someone ask for an example?
    http://addons.miranda-im.org/details...ewfile&id=2995
    http://addons.miranda-im.org/details...ewfile&id=3037 (only work on Windows NT/2000/XP/2003 ???)
    http://addons.miranda-im.org/details...ewfile&id=3694 (Requirement + Description=confusing)
    http://addons.miranda-im.org/details...ewfile&id=4036 (Where I can download Miranda 0.7???)
    This 4 plugins from the current 20 Top Downloads have ugly requirements=20% => About 3000 plugins overall = 600 plugins with ugly requirements. o_O
    If I assume that all this text come from an author, no offense, but no thanks if the authors should fill this fields.
    I don't know the reasons why 600 plugins have ugly requirements or dependencies, but don't tell me it's not true!
    And please don't tell me that everything will get better in the future!

    Volunteers?
    *YOU*, yes I mean YOU, would you do this? Can I see YOU in this team 2011? Would YOU install Clist_x and Message-Window_Y to see if a new plugin works?
    Be serious, someone have any good experience with volunteers here, especially if they MUST do something?

    Community?
    I think that's the only possible way, but I haven't any idea how.

    But on the other side, don't forget how important are correct requirements and "Not work with...", we can't await that any new user search around in the forum, the wiki or the IRC channel.
    Miranda stay and fails with correct working plugins.
    Anything will be better in future ;) The current requirement system is useless because there aren't any dependences... only a text field. We could create categories like "CList Modern" (under "Contact List" under "Themes") that forces to enter a dependency. Sure, the GUI needs to be simple, so adding a dependency to requirement list will take few seconds.
    So anything than a text field is more flexible and can be changed/used in an other way later...

  3. #23
    Join Date
    September 2006
    Location
    Finland
    Posts
    2,852
    One way to maintain it could be a tagging system. There could be the authors selection and complementary list by the users. The "tag" list would be accepted based on the structure (or plugins on the addons) instead of whatever members want to write here to tag threads. That would take some burden off the developers and keep the system coherent.

  4. #24
    Join Date
    August 2005
    Posts
    25
    This is getting somewhere else, than it was before. I guess, at first, we could set up basic terms. Dependency and compatibility are two totally different words.

    Dependency:
    Useful for addons, binaries. Not once, I've been presented a "XXX.dll is missing" when I updated an addon. The developer of the addon should know what he's messing with, and what the user should have. This is the type of information that's missing for some addons. What's worse - when an addon requires a VC runtime dll, it's a BIG problem even for me to find/download it, because MS's dynamic library downloads are ... let's say it politely ... useless. And what's even worse, there are sites, that offer "missing dll's", however, often infected, so the users might blame MIM for having a virus, because MIM asked for that library and he downloaded it. This is why I loved programming in Delphi, there were NO dependencies, if you decided to compile a standalone app. But that's another story.

    Borkra, I know that as a developer, you can't test everything. But still, YOU're the only one, who created the addon, and YOU know, what it does, and what functions of which addons it requires. I'm not saying that the developers ought to test every possibility there is, just - work with a vanilla install. Take it from the user's view. Let's say you are creating something upon tabsrmm and popupplus. Have a clean MIM handy, with tabsrmm on. Does your addon work? No. What does it require (apart from the default install)? We said popupplus. So, download and "install" the popup plus addon. Restart. Does it work? YES. And this is exactly what we need to address. These step-by-step, trial-and-failure processes, because users hate it.

    Ideally, when the user chooses to install an addon package, miranda should read from the package, that it needs tabsrmm and popup. Miranda would display a compatibility dialog, saying, that the addon requires tabsrmm (it's installed by default, check if it's set as default messaging engine, if not, offer the user to switch to it) and popupplus (if it's not available, offer to automatically download and install it before installing the wanted addon). This way, the user only chooses a wanted addon, approves switching to tabsrmm and installing popupplus beforehand. A single "ok" click in an "install dialog".

    Compatibility:
    When I create a skin, again, I'm creating it for a certain addon. When I create it for clist_modern, I KNOW it will work there. But I won't confirm it's looks in clist_modern_mod1, clist_modern_xxx, clist_modern_asdX, because those are NOT the ones I skinned. They MIGHT work, but I rather let others note, that it also works for them. The point is to STANDARDIZE things finally. To don't drag a new user to messing with addons and trying and fixing and hoping he'll set up things without hassle. Simple process - download and install MIM, you want popups? here are 3 options, this looks fine? here's what it needs, here are skins that go with it. click, install. approve dependencies? ok. installed, restarting. bingo, here we go. mission completed.

  5. #25
    Join Date
    June 2005
    Posts
    11,839
    Quote Originally Posted by deb00t View Post
    Useful for addons, binaries. Not once, I've been presented a "XXX.dll is missing" when I updated an addon. The developer of the addon should know what he's messing with, and what the user should have. This is the type of information that's missing for some addons. What's worse - when an addon requires a VC runtime dll, it's a BIG problem even for me to find/download it, because MS's dynamic library downloads are ... let's say it politely ... useless. And what's even worse, there are sites, that offer "missing dll's", however, often infected, so the users might blame MIM for having a virus, because MIM asked for that library and he downloaded it. This is why I loved programming in Delphi, there were NO dependencies, if you decided to compile a standalone app. But that's another story.
    Well, this problem exist because developers do not know or understand. So adding requirement field will not solve anything.

    We have dll dependency to reduce program size, Delphi is incredibly wasteful, this is why I do not allow any plugin written in Delphi on my compute, and you can compile Delphi with dll dependencies as well.

    Quote Originally Posted by deb00t View Post
    Borkra, I know that as a developer, you can't test everything. But still, YOU're the only one, who created the addon, and YOU know, what it does, and what functions of which addons it requires. I'm not saying that the developers ought to test every possibility there is, just - work with a vanilla install. Take it from the user's view. Let's say you are creating something upon tabsrmm and popupplus. Have a clean MIM handy, with tabsrmm on. Does your addon work? No. What does it require (apart from the default install)? We said popupplus. So, download and "install" the popup plus addon. Restart. Does it work? YES. And this is exactly what we need to address. These step-by-step, trial-and-failure processes, because users hate it.

    Ideally, when the user chooses to install an addon package, miranda should read from the package, that it needs tabsrmm and popup. Miranda would display a compatibility dialog, saying, that the addon requires tabsrmm (it's installed by default, check if it's set as default messaging engine, if not, offer the user to switch to it) and popupplus (if it's not available, offer to automatically download and install it before installing the wanted addon). This way, the user only chooses a wanted addon, approves switching to tabsrmm and installing popupplus beforehand. A single "ok" click in an "install dialog".
    You know why developers including me stopped using addons it's because, we share with you what works for us, not more. The rest is your problem. Nearly nobody willing to provide level of support you demand.

  6. #26
    Join Date
    August 2005
    Posts
    25
    Well, this problem exist because developers do not know or understand. So adding requirement field will not solve anything.
    Well, that's pretty bad if even the devs don't.

    We have dll dependency to reduce program size, Delphi is incredibly wasteful, this is why I do not allow any plugin written in Delphi on my compute, and you can compile Delphi with dll dependencies as well.
    No point going through this, I'm completely aware of the reasons, just noted that as one of the problems that occurs for new users, pretty much everytime. They have no idea where to get the missing dlls, not even know what a dll is. Not talking about that they need to be installed by an install package with even more eulas, confirmations, and who knows what. Users HATE installers. Even I do, I just got used to it, because I can't avoid them anyway.

    You know why developers including me stopped using addons it's because, we share with you what works for us, not more. The rest is your problem. Nearly nobody willing to provide level of support you demand.
    We're on the same boat here ;) You created an addon that works with this, this, and that. Finito. You're not the one who will/can test it with other mods or combinations. When someone complains that it doesn't work for them because they're using something else, screw them, if you don't have time to fix that. It's your time, not theirs. But you know that it does work, and exactly with what, so you should indicate that. Without this, the addons won't ever be a nice place for lame users :)

  7. #27
    Join Date
    September 2006
    Location
    Finland
    Posts
    2,852
    Quote Originally Posted by deb00t View Post
    Ideally, when the user chooses to install an addon package, miranda should read from the package, that it needs tabsrmm and popup. Miranda would display a compatibility dialog, saying, that the addon requires tabsrmm (it's installed by default, check if it's set as default messaging engine, if not, offer the user to switch to it) and popupplus (if it's not available, offer to automatically download and install it before installing the wanted addon). This way, the user only chooses a wanted addon, approves switching to tabsrmm and installing popupplus beforehand. A single "ok" click in an "install dialog".
    Downloading and installing other plugins automatically gets quite complicated when someone installs more than one plugin.

  8. #28
    Join Date
    August 2005
    Posts
    25
    Quote Originally Posted by Sami View Post
    Downloading and installing other plugins automatically gets quite complicated when someone installs more than one plugin.
    Saying that doesn't solve anything :) the only complication there might be is, that some addons "conflict" with others, like PopUpPlus and ... the other one :) you certainly don't want 2 popup modules to be running simultaneously. But this kind of conflict is pretty unique, and usually, the plugins avoid it - like, you can't have both srmm and tabsrmm checked in addons, they switch between themselves. Anyway, this could require some in-depth analysis, because without knowing it, it's pretty tough to think about how the "installer" should work :)

  9. #29
    Join Date
    September 2006
    Location
    Finland
    Posts
    2,852
    Quote Originally Posted by deb00t View Post
    Saying that doesn't solve anything :) the only complication there might be is, that some addons "conflict" with others, like PopUpPlus and ... the other one :) you certainly don't want 2 popup modules to be running simultaneously. But this kind of conflict is pretty unique, and usually, the plugins avoid it - like, you can't have both srmm and tabsrmm checked in addons, they switch between themselves. Anyway, this could require some in-depth analysis, because without knowing it, it's pretty tough to think about how the "installer" should work :)
    The conflicts wouldn't be a big issue. If a user installs My Details and IEView, he/she needs also Scriver or tabSRMM and Modern or Nicer contact list.

    How can these be presented so that the user knows what's coming?
    How can the user go back to what was before installing My Details and IEView?
    After a few installs, is it possible for the user to know why he/she has all the plugins?

    And there should be a possibility to disable it because, well, you know what many people think about things that always want to "help" you. :)

  10. #30
    Join Date
    June 2005
    Posts
    11,839
    Quote Originally Posted by deb00t View Post
    But this kind of conflict is pretty unique, and usually,
    You are incorrect it's not unique at all it's widespread.

    Quote Originally Posted by deb00t View Post
    the plugins avoid it - like, you can't have both srmm and tabsrmm checked in addons, they switch between themselves.
    That's because SRMMs are treated as core module, no other plugin is. Actually what we do with SRMMs is unique, no other plugin has this capability.
    Last edited by borkra; 9 Jul 2010 at 12:09 PM.

Similar Threads

  1. Miranda's Database structure
    By Dolonet in forum Technical Support
    Replies: 1
    Last Post: 13 Jul 2007, 10:50 PM
  2. Addon/Pluginpage
    By Slaktarn in forum Website
    Replies: 1
    Last Post: 1 Jun 2007, 7:49 AM
  3. Replies: 1
    Last Post: 27 Nov 2006, 4:22 AM
  4. Please Help - Database Structure Corrupt
    By bugfoot in forum Technical Support
    Replies: 0
    Last Post: 28 Jan 2006, 2:20 PM
  5. Better structure of Miranda directory...
    By Adam2 in forum Feature Requests
    Replies: 4
    Last Post: 5 Apr 2005, 1:18 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •