Since Christmas is around the corner i thought i would post my wishes for the Curse Client:
1) Disembedded libraries / dependencies
I have lost sometime debugging errors, where an 'old' pachage shipped a different version than the current one. I would ease a lot of work if the curse client would be aware of dependencies and install packages as disembedded addons - maybe even removing unused libraries once it dependant addon(s) gets uninstalled.
2) talk with me
I know that CC shall be userfriendly. But for me it's too userfriendly. I install an addon for a 3-rd party website and after i have started the Cc it hijacks said addon and maintains it as if it was on its own (but should actually be tracked and updated by a different program).
It would be great if the client would inform me about addons it has found and wether or not i want Cc to update it or not.
3) history for the forgetfull
It would be great if Cc would keep a log-file about things he has done and access it from within the client, so i could see what it has done during the past runs - sometimes addon erros do not surface emmidiately.
4) Changelog summary
If an addon gets update it would be nice to read a summary of all changes that happened during the last update or a continous log file appending the changes between the installed versions.
Since Christmas is around the corner i thought i would post my wishes for the Curse Client:
1) Disembedded libraries / dependencies
I have lost sometime debugging errors, where an 'old' pachage shipped a different version than the current one. I would ease a lot of work if the curse client would be aware of dependencies and install packages as disembedded addons - maybe even removing unused libraries once it dependant addon(s) gets uninstalled.
Alpha 6 is receiving full alternate package support. (nolibs + dependency resolution)
I know that CC shall be userfriendly. But for me it's too userfriendly. I install an addon for a 3-rd party website and after i have started the Cc it hijacks said addon and maintains it as if it was on its own (but should actually be tracked and updated by a different program).
It would be great if the client would inform me about addons it has found and wether or not i want Cc to update it or not.
This behavior has changed in the latest alphas. We only work with an addon now if we know _absolutely_ that it's what we think it is. And if you want to talk further find me on irc :)
It would be great if Cc would keep a log-file about things he has done and access it from within the client, so i could see what it has done during the past runs - sometimes addon erros do not surface emmidiately.
Right now we have per session logging, is persistance something that we really want/need?
If an addon gets update it would be nice to read a summary of all changes that happened during the last update or a continous log file appending the changes between the installed versions.
I'm not sure sure how this would behave, more feedback is welcomed.
Right now we have per session logging, is persistance something that we really want/need?
I could imagine a persistent log file being useful for helping people isolate conflicts between addons. Imagine:
guildie1: Hey, My SuperZomgAddon isn't working today! whiskytangofoxtrot! guildie2: Huh, mine works just fine. What's in your CC log? guildie1: Let's see... looks like CC updated SZA to v22, LibCoolStuff to v9 and LibLameStuff to v42 this morning. guildie2: Well, my CC updated yesterday and only got SZA v22 and LCS v9, so maybe you should revert your LLS? guildie1: Hey, that worked! Neato burrito!
If an addon gets update it would be nice to read a summary of all changes that happened during the last update or a continous log file appending the changes between the installed versions.
The issue with this is that most packager-generated changelogs are actually full changelogs e.g. from rev 1 to HEAD. Isolating each changes would be necessary before doing what you proposed.
@Kaelten: I'm not sure but I think he is referring to what WAU did : when you updated addon XXX from revision 52 to revision 56, it listed all the log message from revision 53 up to, and including, revision 56.
Alpha 6 is receiving full alternate package support. (nolibs + dependency resolution)
This behavior has changed in the latest alphas. We only work with an addon now if we know _absolutely_ that it's what we think it is. And if you want to talk further find me on irc :)
Right now we have per session logging, is persistance something that we really want/need?
I'm not sure sure how this would behave, more feedback is welcomed.
dependencies: Great
Addon hijacking: so far i have only encountered Cc adding new addons to the list without telling me about it (maybe i forgot to check an option that i want to know about it.
Persistant history: I find it useful, as errors may come up a day / update later and the previous updates (that induced the conflict) can no longer be tracked down.
Changelog: The functionality Adirelle described - e.g. for update R52->R58 the client listing the entries for those would be great. With summary i meant a single page. I'll quote my changelog emails from apt for that:
cups (1.3.8-1lenny4) unstable; urgency=high
* High urgency due to security bug fix.
* Add png-image-int-overflow.dpatch: Fix integer overflow in the PNG image
reader (Closes: #507183, STR #2974, CVE-2008-5286)
-- Martin Pitt [EMAIL="mpitt@debian.org"]<mpitt@debian.org>[/EMAIL] Mon, 01 Dec 2008 17:33:18 -0800
cups (1.3.8-1lenny3) unstable; urgency=medium
* Urgency medium because of RC bug fix.
* debian/cups-bsd.postinst: Assume default printcap path (in /var/run/cups/)
if not specified in cupsd.conf. This brings back the lost /etc/printcap
for legacy applications. (Closes: #482186, LP: #282667)
* hpgl-regression.dpatch: Replaced with version which got committed
upstream.
* Add runloop-backchannel-eof-spin.dpatch: Fix backend runloop spin on
backchannel EOF (select() returns "ready for read" on EOF). This
completely broke printing with e. g. HPJetDirect. Thanks to
Samuel Thibault for tracking down the problem! (Closes: #489045)
* debian/rules: Install the serial backend with 0744 permissions to make it
run as root, since /dev/ttyS* are root:dialout and thus not accessible as
user "lp". Thanks to Chanoch (Ken) Bloom. (One part of #506181)
-- Martin Pitt [EMAIL="mpitt@debian.org"]<mpitt@debian.org>[/EMAIL] Thu, 20 Nov 2008 09:05:35 +0100
Urgency might not qualify for addons, yet it could be used to differ between critical bug fixes and feature enhancements (like translations). The main tree (stable, unstable, testing) could translate into release, beta, alpha.
for addons that CC rejects we should get some sort of easy way to link the rejected addon to one found on curse and then update it to the version on curse
5) show the installed version
Using the date is ok if the addon is only hosted on curse. But sometimes authors move about. It would be nice if the installed / available version would list the version in addition to the date.
Are the toc's updated automatically to the tagged versions?
5) show the installed version
Using the date is ok if the addon is only hosted on curse. But sometimes authors move about. It would be nice if the installed / available version would list the version in addition to the date.
Are the toc's updated automatically to the tagged versions?
The developer has to choose to embed the tag-version in the .toc's Version field.
Every single addon I've downloaded from Curse that's packaged from a CurseForge or WowAce repository (as opposed to being manually zipped and uploaded by the author) has a "X-Curse-Packaged-As" (or something) field added to the TOC, containing the tag name. The client could easily look at this field, or fall back on the standard "Version" field for manually uploaded zips.
for addons that CC rejects we should get some sort of easy way to link the rejected addon to one found on curse and then update it to the version on curse
Every single addon I've downloaded from Curse that's packaged from a CurseForge or WowAce repository (as opposed to being manually zipped and uploaded by the author) has a "X-Curse-Packaged-As" (or something) field added to the TOC, containing the tag name. The client could easily look at this field, or fall back on the standard "Version" field for manually uploaded zips.
The method we're using in the alpha's is much more exacting than that really.
It would be nice if the Client could be make aware of a second Wow install, the PTR. But lets get the other stuff out first. Is there any releasable version ready ?
FYI, My alpha5 version is pulling double duty.. using it to keep both mine and my wife's installs of wow, up to date. (She has a PPC mac, or she'd be running the mac version.. and I have a winbox) So.. I have her wow folder mapped to a local disk on my machine.. have the second wow installation pointing at the other "hard drive" and voila. I can keep multiple versions of wow updated, all with the same program.
So.. yea.. it -is- possible with the alpha version, and I hope it stays in.
break19.
PS. Kaelten said to PM him if you want alpha info.. scroll up..
Yep it is possible, and will remain in, Theoretical could have unlimited games managed, but practicality saysa bout 6 or 10 games is the max.
Err, Kaelten, my alpha5 version auto-updated to alpha 7b, this is good.. however, it's now downloading libraries, even tho I have mine set to use the embedded versions, and I don't see any option to disable said "feature" :p
I am sure it's not finished, hence the "alpha" just want to get this report in, in case that little bug isn't a known one, yet. :)
Since i can disable auto-update. Would it be possible to add an 'update all' button. I prefer issuing an update myself than a box doing that without me knowing about it. (I tried to mark multiple updates with shift. Still the update button would only update one).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
1) Disembedded libraries / dependencies
I have lost sometime debugging errors, where an 'old' pachage shipped a different version than the current one. I would ease a lot of work if the curse client would be aware of dependencies and install packages as disembedded addons - maybe even removing unused libraries once it dependant addon(s) gets uninstalled.
2) talk with me
I know that CC shall be userfriendly. But for me it's too userfriendly. I install an addon for a 3-rd party website and after i have started the Cc it hijacks said addon and maintains it as if it was on its own (but should actually be tracked and updated by a different program).
It would be great if the client would inform me about addons it has found and wether or not i want Cc to update it or not.
3) history for the forgetfull
It would be great if Cc would keep a log-file about things he has done and access it from within the client, so i could see what it has done during the past runs - sometimes addon erros do not surface emmidiately.
4) Changelog summary
If an addon gets update it would be nice to read a summary of all changes that happened during the last update or a continous log file appending the changes between the installed versions.
1) Disembedded libraries / dependencies
1) Disembedded libraries / dependencies
1) Disembedded libraries / dependencies
1) Disembedded libraries / dependencies
1) Disembedded libraries / dependencies
1) Disembedded libraries / dependencies
Alpha 6 is receiving full alternate package support. (nolibs + dependency resolution)
This behavior has changed in the latest alphas. We only work with an addon now if we know _absolutely_ that it's what we think it is. And if you want to talk further find me on irc :)
Right now we have per session logging, is persistance something that we really want/need?
I'm not sure sure how this would behave, more feedback is welcomed.
I could imagine a persistent log file being useful for helping people isolate conflicts between addons. Imagine:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe issue with this is that most packager-generated changelogs are actually full changelogs e.g. from rev 1 to HEAD. Isolating each changes would be necessary before doing what you proposed.
@Kaelten: I'm not sure but I think he is referring to what WAU did : when you updated addon XXX from revision 52 to revision 56, it listed all the log message from revision 53 up to, and including, revision 56.
dependencies: Great
Addon hijacking: so far i have only encountered Cc adding new addons to the list without telling me about it (maybe i forgot to check an option that i want to know about it.
Persistant history: I find it useful, as errors may come up a day / update later and the previous updates (that induced the conflict) can no longer be tracked down.
Changelog: The functionality Adirelle described - e.g. for update R52->R58 the client listing the entries for those would be great. With summary i meant a single page. I'll quote my changelog emails from apt for that:
Urgency might not qualify for addons, yet it could be used to differ between critical bug fixes and feature enhancements (like translations). The main tree (stable, unstable, testing) could translate into release, beta, alpha.
Where we can get Alpha 6 for testing ? ;D
Using the date is ok if the addon is only hosted on curse. But sometimes authors move about. It would be nice if the installed / available version would list the version in addition to the date.
Are the toc's updated automatically to the tagged versions?
The developer has to choose to embed the tag-version in the .toc's Version field.
Example:
## Version: @project-version@
Coming in Alpha7 :)
The method we're using in the alpha's is much more exacting than that really.
It would be nice if the Client could be make aware of a second Wow install, the PTR. But lets get the other stuff out first. Is there any releasable version ready ?
-
View User Profile
-
View Posts
-
Send Message
Project Author-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis was already listed in the planned features news post.
So.. yea.. it -is- possible with the alpha version, and I hope it stays in.
break19.
PS. Kaelten said to PM him if you want alpha info.. scroll up..
Err, Kaelten, my alpha5 version auto-updated to alpha 7b, this is good.. however, it's now downloading libraries, even tho I have mine set to use the embedded versions, and I don't see any option to disable said "feature" :p
I am sure it's not finished, hence the "alpha" just want to get this report in, in case that little bug isn't a known one, yet. :)
break19
e.g.: http://wow.cursebeta.com/downloads/wow-addons/details/roleplaying-helper-2.aspx
Since i can disable auto-update. Would it be possible to add an 'update all' button. I prefer issuing an update myself than a box doing that without me knowing about it. (I tried to mark multiple updates with shift. Still the update button would only update one).