Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Album Art Downloader XUI (Read 2066435 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Album Art Downloader XUI

Reply #975 –
I've been thinking some more about command line behaviour, and I'm no longer so convinced that they should always be temporary. Maybe I had the right idea when they were implemented the first time. So, some possible options for command line behaviour - opinions, anyone?

1. Command line settings are all always temporary. Any new searches performed by the user will use their existing settings, ignoring the command line parameters.
  1 a. In the search window launched by the command line, all settings are disabled, the user can't change them as they have been fixed by the command line parameter.
  1 b. Settings are enabled, but any changes made to them are discarded when the window is closed.
  1 c. Settings are enabled, and if the user makes any change to them, those changed settings are saved when the window is closed (replacing users existing settings).
2. Command line settings are always permanent. Settings specified by the command line are saved as settings when the user closes the search window.
  2 a. Certain documented command line settings do not affect settings. Currently, /autoclose has this behaviour, and the proposed /sourcesFirst would too.
  2 b. An additional parameter to specify setting permanence is added. /temporary or something, which would result in one of the behaviours in 1 when present.
  2 c. Each parameter can have permanence set for it. So /t:minSize would be a temporary setting of minimum size, /p:minSize would save it in the settings. For the ones set as temporary, one of the  behaviours in 1 would apply.

Bear in mind that the more complex or difficult the chosen option, the lower the chance of it actually ever getting implemented, and the greater the time before it does! For example, 2. a. is almost exactly the current behaviour, just with some additional documentation in the command args documentation.

Alex

Album Art Downloader XUI

Reply #976 –
Quote from: AlexVallat on
I've been thinking some more about command line behaviour, and I'm no longer so convinced that they should always be temporary. Maybe I had the right idea when they were implemented the first time. So, some possible options for command line behaviour - opinions, anyone?

I always thought of command line options as switches for the advanced user.

Something in the lines of "those commands are either too advanced, or secondary, or, ultimately, they would clutter the interface, so I'm giving them to power-users"; or to allow the program to be launched from other applications".

Being like that, I think the best way to get your program to act with those switches is always to create a shortcut that incorporates those switches; or have another application call the program with the right switches by programming this other app to do so. I can't really believe anyone would type the command line over and over again. So, long story short, I personally think the settings should be temporary, because they're probably being passed on each time the program is started (either in the shortcut or in the programmed call being made by the other app).

I believe that anything permanent should always be accessible, i.e. written somewhere, either in some tab inside the program (and probably the registry) or in some .ini file in the folder, or something like that. This way it can always be checked and changed (or, even better, made backup and restored). If someone want to make any of those permanent changes temporary, the best way would be to backup the .ini file, write another one and restore the original at the end.

Specifically for this program, I think like this:
- you either consider the command line calling as "a session" with its own specific settings (and all windows will use those settings, until the program is closed); The problem is (as you already have considered in 1b & 1c), if the user wants to change something in the middle of the session, should you consider that a permanent change or not? Should you change permanently only this changed option or all of the session's settings? That is a dilemma and both ways have their pros and cons. Ultimately, it's a personal choice of the programmer.
- or you think of it as an "automatic way to change settings", which is fine, as long as those are clear rules, i.e. when you start with comm.line your old settings are gone (but you can always have another shortcut with the old settings to restore them the next time, if you want to).

Both ways are OK, but I like the first (a session) a bit more. What I would really like though, is to have access to a settings (.cfg or .ini) file to make direct changes and backups of settings. It would also be nice (obviously in the future, as it would take a lot of extra work) to have groups of different settings selectable inside the program (maybe a pulldown menu), so you don't have to keep restarting the program or making a whole bunch of manual changes from time to time.

1. ...always temporary. Any new searches will use existing settings
--> ok, but I think this would generate confusion, as the user doesn't know that the settings he used to call the program are not valid anymore.
  1a ...all settings are disabled
--> don't like it at all. The user might (and probably will) want to change settings to accommodate for different types of results.
  1b ...enabled, but changes are discarded
--> ok, but I think this might generate confusion, especially if the user always starts the program using command line switches.
  1c ...enabled ...any change ...settings are saved (replacing existing)
--> the best option so far. In my opinion, the user never gets to choose if his change is temporary, unless you want to add another switch that deliberately says so or if you want to incorporate this kind of settings in the program (like 2b & 2c), both adding to the complexity of the program, like you said yourself. (personally, I don't think this is the best option, I would go with 1b, but for the general user, 1c/2c yes)

Album Art Downloader XUI

Reply #977 –
Quote from: audio20 on
What I would really like though, is to have access to a settings (.cfg or .ini) file to make direct changes and backups of settings

Thank you for your long and considered post, it certainly gives me points to think about. In answer to your specific issue about access to settings in a file, the settings are stored in the file:

\Documents and Settings (in XP, or in Vista:) \Users\<user name>\Local Settings\Application Data\AlbumArtDownloader\AlbumArt.exe_Url_<random junk>\0.30.0.0(or version number of AAD that you are using)\user.config

This is an XML file, which can be user-edited, copied, backed up or whatever. AAD stores no user settings in the registry.

Alex

Album Art Downloader XUI

Reply #978 –
Quote from: AlexVallat on
The info-bar thing is not a bad idea, but I'm thinking it might be better to put it inside the results list, at the bottom, rather than floating above it. That way, if you scroll through all your results and still haven't found what you're looking for, a link with "Continue search with other selected sources..." (or similar, not dead set on the wording yet) would be there.

Inside? Yes. Floating? That wasn't my idea, and the picture shows that it's not floating, i.e. covering anything. Remember that a large monitor, maximized AAD window & only few results, user might not glance to the bottom part at all. Try it at the top at least and see if that's good or bad. EDIT: Did you mean that you'd put it as a "source" in the end of the list? That sounds ok but what about if a user has e.g. sorting on which puts high resolution pictures at the top and there's so much results that your "infobar" would not be visible without scrolling? The user might not scroll down if the best results are at the top part. Just a thought.

A link in it? So the user would only click that infobar (link) and it would execute the 2nd search? Hmm, could be good, something is bothering me with that but can't pinpoint what.. so I guess the idea is good then.

Quote from: AlexVallat on
...would that meet your needs for REACT?

I'll try to vote on the command line behavior thing thinking about it in general and with REACT in my mind.

Album Art Downloader XUI

Reply #979 –
Quote from: Akkurat on
there's so much results that your "infobar" would not be visible without scrolling? The user might not scroll down if the best results are at the top part.
That's kind of the point. If they have results so good they don't even need to scroll to see the others returned by the first search, then they certainly don't need to do the second search! If they don't find anything they like, when they reach the bottom of their results, the link will be there allowing them to find some more.

Album Art Downloader XUI

Reply #980 –
Quote from: AlexVallat on
2. Command line settings are always permanent. Settings specified by the command line are saved as settings when the user closes the search window.
I think that this is the only reasonable option. /sourcesFirst would be permanent (consistent with the other switches/settings that can be changed and they are permanent).. and one could use it to turn ON and OFF "sourcefirst" options (I guess it needs /sourcesFirstOn and /sourcesFirstOff switches). Also make the /autoclose permanent. And with the modification that "Settings specified by the command line are saved as settings when the user closes the search window". I.e. if the user changes the settings, those are NOT reverted to the command line settings that were used.

Some of the 1x options would be too confusing for the user (1c especially) and all of them would require notifications in the GUI.

Album Art Downloader XUI

Reply #981 –
Quote from: AlexVallat on
If they have results so good they don't even need to scroll to see the others returned by the first search, then they certainly don't need to do the second search! If they don't find anything they like, when they reach the bottom of their results, the link will be there allowing them to find some more.
That's not what I meant. Let me rephrase that. If a user has e.g. sorting on which puts high resolution pictures at the top and there's so much results that your "infobar" would not be visible without scrolling? The user might not scroll down if the best results images with sizes that the user is interested in are at the top part. I.e. user don't accept under 600px images and the first visible result page shows images under that limit e.g. from the halfway down. One could argue that why doesn't that user use "minsize" option then.. well, everybody uses the program their own way and devs should think about every possible situation. The point is that IMHO you should have the info always visible! And with your suggested idea, I see that it could be missed by some users.. I wouldn't leave that possibility, but you're the dev here, you do what you think is the best. I don't get any pleasure arguing stuff over here, usually the users who engage in these kind of conversations are truly interested to help making the app better.. just saying in case I'm misunderstood (wouldn't be the first time.. sadly.. this depresses me a lot in general.. and it makes me always question if I got the message across).
 

Album Art Downloader XUI

Reply #982 –
Quote from: Akkurat on
I think that [all command line settings are permanent] is the only reasonable option.
OK, thanks for your opinion. I agree, in general, but I know that having autoclose not affect the user settings was a requirement when autoclose was originally implemented. There's a similar case now for /sourcesFirst. The two options I'm now considering are either having just those two non-permanent (2a), or having a general purpose system to specify whether a parameter is permanent or not (2c).

Quote from: Akkurat on
And with your suggested idea [for where to put the "continue searching" link], I see that it could be missed by some users...
I think I see what you're saying, that there are plenty of results returned by the first search, but that due to their sorting preferences, the user will assume that if they can't see good results in the top few, then it isn't worth even scrolling down to see what other results are available? I'll have a think about that, but I'm also not convinced it's worth taking up a whole non-scrolling horizontal line of space all the time for this.

Album Art Downloader XUI

Reply #983 –
Quote from: AlexVallat on
Thank you for your long and considered post, it certainly gives me points to think about.
You're wellcome. I think it's the least we can do for you. 

Quote
In answer to your specific issue about access to settings in a file, the settings are stored in the file
[font= "Courier New"]\Documents and Settings [font= "Arial"](in XP, or in Vista:)[/font] \Users\<user name>\Local Settings\Application Data\AlbumArtDownloader\AlbumArt.exe_Url_<random junk>\0.30.0.0[font= "Arial"](or version number of AAD that you are using)[/font]\user.config[/font]
This is an XML file, which can be user-edited, copied, backed up or whatever. AAD stores no user settings in the registry.

That's a great thing to know, indeed. Thank you very much for this information.

I know it's not your fault at all, it's MS's fault to design such a flawed system as windows, where you have to bury the settings file so deep that a regular user won't find it unless he goes "on a hunt" for it. I also realize that I might have given you enough "trouble" already, but you might consider (in the future) including an option in the installer a lot of some great apps like yours do:

When running the installer for windows, give the user a "Portable" option, where he will choose a path that is outside the windows default path for programs (and therefore without write permission problems) and store the settings file inside the actual program folder (they just check each run if there is a settings file in the program folder and use that instead of that deep-buried one).



The major advantage of it is not, as it might seam at first, to have the settings file inside the program folder. The beauty of it is that the user can actually copy and more the program folder around multiple times and the program still works consistently with all the settings he established before. It's also nice to be able to run the program from a USB stick and modify and keep the settings there.

Album Art Downloader XUI

Reply #984 –
Quote from: audio20 on
just check each run if there is a settings file in the program folder and use that instead of that deep-buried one
If you put a file called AlbumArt.exe.config in the program folder, settings within that will be read from that. It does not override the user settings file, though, the user settings file overrides, and is what the changed settings are written to. This is because there will typically not be write permissions to the program folder.

This is clearly not the Portable Mode you requested, but you might find it helpful. It is just the standard behaviour for .net configuration settings.

Album Art Downloader XUI

Reply #985 –
Quote from: AlexVallat on
If you put a file called AlbumArt.exe.config in the program folder, settings within that will be read from that.
That is also very good to know! It will allow us to have a USB stick with AAD and one fixed preconfigured settings. (It's not ideal, but already great, Thanks a lot!  )


Quote
This is because there will typically not be write permissions to the program folder.
I knew that, but I thought that was only valid if the program folder was actually inside "%PROGRAM_FILES%"; outside that path you would have normal write permissions.

Quote
This is clearly not the Portable Mode you requested, but you might find it helpful. It is just the standard behaviour for .net configuration settings.
Indeed. It is helpful. I have no experience whatsoever with .NET, so I can only hope you'll find out the write permission issue is only valid for the default program files path and not outside of it as it is in other cases for other languages. That way you still might have the portable option in future versions. Otherwise, I'm very happy with what I've already got right now. 

Album Art Downloader XUI

Reply #986 –
Quote from: Akkurat on
Quote from: AlexVallat on
2. Command line settings are always permanent. Settings specified by the command line are saved as settings when the user closes the search window.

I think that this is the only reasonable option.

Hi, Akkurat,
I'm sorry to say this, but really? Are you thinking about users in general or are you more concerned with users that call AAD from another program?

What if I personally want to have different settings set up at different shortcuts for the program? (and I don't want to mess up my "standard" settings everytime I exit the program, after one of those calls). Isn't that reasonable?

Quote
Some of the 1x options would be too confusing for the user (1c especially) and all of them would require notifications in the GUI.

An interface with too many warnings is a cluttered interface... A user that calls a program with command line options isn't a user that get confused that easily also.

Quote from: AlexVallat on
...that there are plenty of results returned by the first search...not convinced it's worth taking up a whole non-scrolling horizontal line of space all the time for this.

I agree with that point of view. Not every user have a huge LCD screen... There is a good possiblity that a lot of users will be using the program in a 15" monitor and a single line is indeed precious space. I also think that this whole warning to the user, for the first time user is a good thing. But very soon, it will be interpreted as an annoyance, because after only a very few seaches (1 or 2) the user will already know that, uless he presses the search button again he won't get more results after the "Search First" sources are done. I'm not for it at all, unless it can be turned off. A more elegant solution would be to change the focus to the search button, or change it's color to indicate there are more possible results. Something in those lines.

Quote
Quote
I think that [all command line settings are permanent] is the only reasonable option.
...I agree, in general... The two options I'm now considering are either having just those two non-permanent (2a), or having a general purpose system to specify whether a parameter is permanent or not (2c).
In that case, would you possibly consider having multiple sets of settings inside the program (as an option)? (the user could modify and save a limited number of settings that could be handled by a pulldown menu in the "...options" panel)

Album Art Downloader XUI

Reply #987 –
Quote from: AlexVallat on
I'm also not convinced it's worth taking up a whole non-scrolling horizontal line of space all the time for this.

Maybe were are thinking different things here again. Is that small yellow bar really taking too much space in my mock up?


Album Art Downloader XUI

Reply #988 –
Quote from: audio20 on
Are you thinking about users in general or are you more concerned with users that call AAD from another program?

I think I've expressed very recently where I'm coming from.. and I don't have to justify my opinion just because you don't happen to like it.

Quote from: audio20 on
What if I personally want to have different settings set up at different shortcuts for the program? (and I don't want to mess up my "standard" settings everytime I exit the program, after one of those calls).

You can now. Just set up shortcuts for every possible need you have. There you go, problem solved. Just because you (or somebody else) could benefit from a more robust settings system, it doesn't necessarily mean that it would be good for the whole userbase, e.g. the feature could bring too much complexity and clutter.. what I'm saying is that there's a fine line of how much developers should develop the app, bring too many options and kitchen sinks.. errm, I mean features, pow, bloatware.

Quote from: audio20 on
An interface with too many warnings is a cluttered interface...

Very true, that's the very reason I don't like the 1x options at all.. and those really require some info in GUI to users. Without info the what would be saved and what not etc. situations could be very hard to understand.

Quote from: audio20 on
A user that calls a program with command line options isn't a user that get confused that easily also.

We could argue with that. I've seen very confused people who use cmd line options, (usually) it's not very hard to put cmd lines switches in to action, understanding what they do is.

Album Art Downloader XUI

Reply #989 –
Quote
Is that small yellow bar really taking too much space in my mock up?
Not really, no. But try at lower resolutions, maybe it will. I think it's an unnecessary annoyance for anybody else's other than the first time user. (That is only one of the reasons why Internet Explorer is loosing so much market share for quite some time now: bad programming behaviors.) I'm not against it, specially if we could turn it off, but I'm really trying to see is this: Would it be worth all the programming time this would take if a good percentage of the users are bound to turn it off? If the developer thinks this will help first-time users try and stay faithful to the program, then "yes, it is", go for it. Otherwise, why not concentrate on more important tasks...

Quote from:  link=msg=657405 date=0
I think I've expressed very recently where I'm coming from.. and I don't have to justify my opinion just because you don't happen to like it.
I completely agree with you on that. I just think you should be more clear about what are you advocating. I don't think you have the average user in mind - at all. I didn't mean to be rude, as I'm guessing you didn't either when you dissed everybody else's choices, instead of just pointing out the virtues in your choice.
Quote
...Just set up shortcuts for every possible need you have.
I don't think that is a very elegant solution, but you're right, it could work.
Quote
Just because you (or somebody else) could benefit...
I decline to respond that. Let's just not go down that way.
Quote
...I'm saying is that there's a fine line of how much developers should develop the app, bring too many options and kitchen sinks.. errm, I mean features, pow, bloatware.
Agreed and agreed.      As Mies van der Rohe used to say, "less is more".
Quote
...that's the very reason I don't like the 1x options at all.. and those really require some info in GUI to users.
Ok, I respect your opinion, but I don't see the need for those infos. The user is very likely to enter the program already knowing that his new changes will or won't be saved at the end. We must consider the 1x as valid options, especially if they are/were/might be so much easier to implement. If you, as an external programmer, want definitive changes, you might very well manipulate directly the config file as shown by Alex earlier.
Quote
...I've seen very confused people who use cmd line options... not very hard to put cmd lines switches in to action, understanding what they do is.
I'm not fully in agreement here, but there's a whole lot of margin for error there. Let's call it a draw.

Finally, I think I fully understand what you are so passionately advocating here, that is an extremely welcome, desired and convenient change in AAD that will allow you to have more control of it, and your own users to have a more pleasant and consistent experience with the program. That's perfectly fine. What I don't like, and I hope you respect my opinion on that, is that you have to go all the way around it to primarily dismiss a great option that all "the other users" (the ones that don't call from an external program) would have: the option to have (at least while there is no option for different settings inside the program) a couple of temporary settings they could alternate once in a while. It's no big deal, really. But first we should discuss respectfully, and only then we come to a verdict.

Album Art Downloader XUI

Reply #990 –
Just a small feedback from a first-time user: I'm using Windows XP and have disabled ClearType font rendering. However, Album Art Downloader XUI uses ClearType without having an option to disable it. I think this should be disabled by default for future versions of this program. It may be a nice program, but the first impression could have been better when ClearType wouldn't have been forced.

Album Art Downloader XUI

Reply #991 –
Quote from: audio20 on
I just think you should be more clear about what are you advocating. I don't think you have the average user in mind - at all.

"I'll try to vote on the command line behavior thing thinking about it in general and with REACT in my mind." Post #979. That was the last time I wasn't clear.

Quote from: audio20 on
I didn't mean to be rude, as I'm guessing you didn't either when you dissed everybody else's choices, instead of just pointing out the virtues in your choice.

LOL. Alex ASKED opinions, I gave mine. I guess you're a bit self-centered if you thought that I dissed your choices (everybody elses? there's only 2 opinions so far, yours and mine). Did I comment on your opinions?

Quote from: audio20 on
We must consider the 1x as valid options, especially if they are/were/might be so much easier to implement.

Here's an interesting point, I was thinking also from Alex's POV (he stated that: "Bear in mind that the more complex or difficult the chosen option, the lower the chance of it actually ever getting implemented..."), as well as in general dev POV, those 1x options need work. That combined with thinking about this from users POV, and my POV.. and from REACT users & dev POV. All these made me choose option 2. Now then, was I really thinking about from my situation only? I don't understand where you got that from.

Quote from: audio20 on
If you, as an external programmer, want definitive changes, you might very well manipulate directly the config file as shown by Alex earlier.

Who said that as an "external programmer" I would like definitive changes? Again, you're drawing your own conclusion from thin air. In fact, if you'd have paid attention, it's quite the opposite. Also manipulating the config file means that I would have to code a parser for that huuuuge settings file, a parser which might get broken with every new AAD release. No thanks. Also I don't like the idea of messing with files that could have who knows what user rights.

Quote from: audio20 on
What I don't like, and I hope you respect my opinion on that, is that you have to go all the way around it to primarily dismiss a great option..

Great and great, who decides that? And like I said, Alex wanted opinions, I gave my opinion about the options he provided.

Quote from: audio20 on
But first we should discuss respectfully, and only then we come to a verdict.

LOL. Verdict? I'm not here discussing and thinking that I'm part of the decision group. LOL. Seriously. Alex has the magic wand here, we don't have to agree and come to a consensus.. we just whine and hope that our opinions count when Alex makes a decision.

EDIT: ytpos

Album Art Downloader XUI

Reply #992 –
Quote from: durch on
Album Art Downloader XUI uses ClearType without having an option to disable it.

This has been discussed in this topic, a "ClearType" topic search yielded a straight answer:

Quote from: AlexVallat on
Quote from: phunkydizco on
I suppose that album art downloader now is a WPF application and that causes this effect. I haven't developed with WPF yet, but I think that there is a possibility to fix that.

It's called anti-aliasing, is part of how the WPF framework draws itself, and as far as I can tell, there is no way to turn it off, sorry. The best I can offer is that it doesn't look so bad if you have ClearType turned on for the system, which isn't really a solution, I know.

Anti-aliasing and clear-type seems to be in fashion at the moment, although I've got to say I'm more in agreement with you that font-fuzzing is not the great step forwards it is made out to be.

Album Art Downloader XUI

Reply #993 –
Akkurat and audio20, I have read the (spirited) discussion, and am paying attention. Here's my current thinking:

1. Portable Mode. Nice to have. This would, however, currently involve replacing the standard .net configuration settings system with something custom written, which is not something I'm particularly interested in doing. I'm not saying it will never happen, but I wouldn't hold your breath. Feature Request

2. Multiple settings sets. Not going to happen. Sorry, but I first encountered such a system in an application called frhed, and it completely confused me then. If it confused me, it will confuse others, and I'm not confident I could present that functionality in a non-confusing way. I'm afraid Akkurat's suggestion to use multiple command lines is your best bet.

3. Command line argument settings persistence. Having reviewed the arguments on both sides, command line arguments will continue to effect persistent changes to user settings. /autoclose will be documented to indicate it's exceptional status.

4. Command line support for Search First. This will happen, but I'm not set on the form it will take yet. I'm thinking at the moment instead of a /sourcesFirst parameter, to extend the existing /sources and /include parameters so they can specify first. For example, /sources "F:Local Files,GoogleImage" would result in only two sources being selected, and Local Files being marked Search First. /include "F:Local Files,GoogleImage", on the other hand, would add the Local Files and GoogleImage sources to the selected sources, without unselecting other already selected sources, and mark Local Files as Search First (if not already so marked), and unmark GoogleImage. These changes would persist in user settings.

5. Indication of Continue Search. In a maximized 1280x1024 screen, yes, an Info Bar like you suggest would take up negligible space. AAD is designed to work well at much smaller sizes than that, even non-maximized on a smaller screen. Please consider a window size of 640x480 when evaluating UI. I'm still of the opinion that scrolling down is a fairly natural behaviour when no acceptable results are visible, but I have taken your point about the sort order, and am still considering alternatives. Any alternative must not be irritating to experienced users, and must absolutely not feel like it is getting in the way. Flashing lights and popup balloons won't do! A non-scrolling bar might be OK, but it would be at the bottom, and not the top, at least.

Album Art Downloader XUI

Reply #994 –
Quote from: AlexVallat on
I have read the (spirited) discussion

Mildly put.

1. IMHO, .NET apps portable? Not so good idea. Anyhow, I always advocate portable software.

4. The extended switch system sounds good.

5. I disagree slightly with some of the points but there's no need for me to repeat myself.  The 640x480 is so 90s (reminds me of an early web design case in the late 90s where the boss was using 640x480 and wanted their company website to fit to that  He almost had a heart-attack when I showed him 800x600.. "put it back, put it back.." LOL), a ~20px high infobar is taking very little space versus all the search fields, etc. AND the source list. I know I know, why add some more. Anyways, I do hope that you'll find a good solution easily.

Thanks for listening.

Album Art Downloader XUI

Reply #995 –
Quote from: Akkurat on
I'm glad you're happy with the extended switch system for Search First. As long as that does what you need for REACT, it's the one I'm going to go with. Updated Feature Request

For continuation of search, I've had another idea. How about if the search button changes text from "Search" to "Extend Search" (on two lines, probably). If I'm feeling artistic, or more realistically if I can find a suitable free icon, I'll have the icon change too. The nice thing is, this would happen if they manually selected any additional sources too, and would revert to just "Search" if they changed the Artist or Album fields. That way they'll have immediate visual feedback on what the button will do when they press it, under all circumstances.

I don't see any reason .net apps shouldn't be portable. Other than having to write your own custom settings mechanism rather than use the standard one, I don't think there would be any other difficulties. It's not like COM where components need to be registered to work! Of course, the Foobar COM Automation thing wouldn't be portable, AAD will work just fine without it. How well it works in practice would really depend on how widespread the .net framework is, really. It's pushed out by Windows Update, and should be part of Vista and 7, but I just don't know.

Alex

Album Art Downloader XUI

Reply #996 –
Alex, I was mainly thinking about it generally, but it suits REACT just fine too. Just making sure that people understand that I was thinking about it in general.. some of your posts could have given other ideas (e.g. "would that meet your needs for REACT?" and "As long as that does what you need for REACT, it's the one I'm going to go with").

The search button thing actually sounds great. If it changes appearance enough for the user to notice it always and it doesn't irritate "exp. users", I'd try that. Good idea.

Album Art Downloader XUI

Reply #997 –
Quote from: Akkurat on
Just making sure that people understand that I was thinking about it in general...
Sorry, that's fine, yes. Of course I want to make sure that the command line is as generally useful as possible, and your opinions on that are most welcome. However, information on whether it will meet the known requirements for a known usage is also very useful to me! If it wasn't going to do the job for REACT, then the design would need re-thinking.

Alex

Album Art Downloader XUI

Reply #998 –
"No matching images found." What does it mean? Network problem? How to test?

Album Art Downloader XUI

Reply #999 –
Here's a random question that might be answered in this 40-page thread.  Haha.  But why do so many images in the search results return unknown image size?  And two, how about an option to prefetch the unknowns and save me 30 clicks.