I'm in a dead mood which basically means my creativity is near zero. As such; jUniUploader has not been progressing much.

I hereby extend my arm to reach toward your creativity and wishes. If anyone has a suggestion, wish or idea for jUniUploader that they would like to see implemented, I shall give it serious considderation.

I was thinking of implementing some character/guild statistics and graphs based on the info from CharacterProfiler, but I'm not sure whether that would actually be useful.

Also remember that jUniUploader is still 100% opensource and its source is quite well documented. You're free to have a peek if you have a basic Java understanding; and invited to make modifications to it as you see fit (even change the application to suit your guild's needs better).

Give me some time with this app. I'm sure that there will be a considerable amount of ideas that will result from asking our guild to start using jUniUploader. I've emailed the link to the webapp to several people and am waiting to hear some feedback from them then we are going to publish it as a link on our homepage.

It would be preferable if the GuildProfiler was not enabled by default or simply removed altogether. The main reason being is that I'd rather not have everyone in the guild having this installed since only one of us actually updates the guild roster.

Perhaps if I understood the intention of the current implementation otherwise, I can't really think of a reason why this is hard-coded.

It would be a "nice to have" feature to allow for the URL icons on the main app page to be stored as properties within the JNLP such that users will not need to enter this information themselves. The icons on the home page are a great idea but it's not likely that your average guild member will take the time to enter this information and I can see where some users would be un-savvy to the point that they wouldn't be able to figure it out.

Similar to the Win32 app, it would be nice if "admins" that are responsible for implementing/hosting the JNLP file to be able to suppress/hide the configuration page. Or perhaps disable all of the fields such that they would be "read-only". (i.e. the users couldn't edit them)

Due to the likelihood that most users won't completely understand the consequences of these parameters, it would be better in most circumstances if they didn't have access to that page at all. I would suggest implementing a property in the JNLP file to toggle this page on and off.

Same could be said for the Addons page.

It would be preferable if the GuildProfiler was not enabled by default or simply removed altogether. The main reason being is that I'd rather not have everyone in the guild having this installed since only one of us actually updates the guild roster.

This question was asked before by ds001. I will quote his question and my reply at the time. I have not changed my mind since.

[quote=ds001]Remove or make an option to not have Guild Profiler in the addon lists by default. Guild Profiler addon is only used by officers and we don't want to have our regular users installing and running it.[/quote]
I can't really show/hide addons from the addon listing from user to user. That is something that'll be the same for all users in your guild, as you probably know. As a result, I find having GuildProfiler in the list as a non-essential addon to be a good compromise. That way, the people that want it and have the necessary password to upload its data can install it, any others can do what they wish (though installing it would be a little useless without the password to upload its data).

If I remove GuildProfiler from the list, then how will your officers keep it up to date? I suppose I could add a little checkbox in the options window "Hide GuildProfiler" which is on by default, but I really don't see the use of such a feature.. :O Enlighten me if you do.

---

Bottom line is, GuildProfiler is added to the list of addons, is not checked for installation by default, which means it's there if a user wants to use it but won't install if the user doesn't. As such, it is not "enabled by default", as you say, but just "always present in the addons list"; leaving the choice up to the user.

---

It would be a "nice to have" feature to allow for the URL icons on the main app page to be stored as properties within the JNLP such that users will not need to enter this information themselves. The icons on the home page are a great idea but it's not likely that your average guild member will take the time to enter this information and I can see where some users would be un-savvy to the point that they wouldn't be able to figure it out.

The URLs are already configurable by you for all your guildies through UniAdmin. There is no need for anyone to manually fill them in unless if you choose not to use UniAdmin.

See the settings 'HOMEURL' and 'FORUMURL'. The Roster URL is automatically derived from the primary upload URL ('PRIMARYURL').

The property fields in the JNLP are only there for settings that are not configurable by UniAdmin. If there are reasons I have not yet considdered for having more fields configurable through the JNLP file then I'd love to hear them.

---

it would be nice if "admins" that are responsible for implementing/hosting the JNLP file to be able to suppress/hide the configuration page. Or perhaps disable all of the fields such that they would be "read-only". (i.e. the users couldn't edit them)

Due to the likelihood that most users won't completely understand the consequences of these parameters, it would be better in most circumstances if they didn't have access to that page at all. I would suggest implementing a property in the JNLP file to toggle this page on and off.

I am not used to the "Windows-theory" of applications. I find any sort of limitation imposed on the user through the application or through the application's administration to be an inconvenience. If a user's not smart enough to deal with configuration then he should stay away from it. I doubt much harm can be done in the configuration pane anyway. As soon as you restart jUU, any settings from UniAdmin override user changes anyway, so if you define some essential settings in UniAdmin, a user can't break things that cannot be fixed with a restart or a resync.

What I can do, is disable the fields that UniAdmin has settings for. Since those fields are reverted to UA defaults upon each sync anyway, there's little point in changing them, ever. That way, you can control which specific settings are read-only (in a way, they are already).

There are settings on the configuration pane which I do not want to deny user access to. I find obfuscation to be a very ill-adviced concept under nearly any and all circomstances.

Same could be said for the Addons page.

I'm not sure I follow you on this point. Do you mean hiding certain Addons? Then don't add them to your UniAdmin listing. Granted, the CP and GP addons will always be added to the list, but this is once again the result of my philisophy that knowledge and choice is power. Taking any of those away, if even a little, always puts the user in a weaker position.
By the way, there should be plenty of explenatory tooltips by now.

Quote::
It would be a "nice to have" feature to allow for the URL icons on the main app page to be stored as properties within the JNLP such that users will not need to enter this information themselves. The icons on the home page are a great idea but it's not likely that your average guild member will take the time to enter this information and I can see where some users would be un-savvy to the point that they wouldn't be able to figure it out.
The URLs are already configurable by you for all your guildies through UniAdmin. There is no need for anyone to manually fill them in unless if you choose not to use UniAdmin.

See the settings 'HOMEURL' and 'FORUMURL'. The Roster URL is automatically derived from the primary upload URL ('PRIMARYURL').

The property fields in the JNLP are only there for settings that are not configurable by UniAdmin. If there are reasons I have not yet considdered for having more fields configurable through the JNLP file then I'd love to hear them.

When I had asked earlier where these settings were stored, you had indicated it was stored in a binary file in the user's home directory on the system the jUniUploader was running from. This is why I was a bit confused and thought that it was a user level aspect as opposed to controlled by the server. I have those variables populated in UNIADMIN so we should be good. Thanks for the info.

Oh. Sorry.

Well, in a way, they are. All settings are in the user's config file. But they can be controlled by UA.

Users that use jUU without UA can just enter them manually and they will only be retrieved from the config file.

Sorry for the confusion.


I've made any UA-controlled settings disabled in the configuation section. I might considder implementing a "basic"/"advanced" UI switch at a later date.

Hi,

Some extra features could be
Somes new buttons on main page to launch Teamspeak or ventrillo application, or Cartographer (http://tixu.scribe.free.fr/indexen.php)

Does button without link be hidden ?

currently a button without a valid link is just grayed out. I suppose I could add a funcionality to add arbitrary applications to the jUU launcher.

Will keep it in mind!

function to read settings.ini on startup...

I'm not sure I understand what you would expect a settings.ini file to be used for. Can you elaborate?

Probably to read a UniUploader settings.ini file

Oh. An import my settings-sort of thingy.

I doubt I'll implement that since most of this can already be achieved through UniAdmin. There's very little to set up; it takes you about 5 minutes to dublicate the setup.

I would like to see a username password field on the main page if the uniadmin config variable for ADDVARNAME1 and ADDVARNAME2 are set. I would like to also offer this to the users on my site using Dragonfly and I believe the post variable are being set by uniadmin (granted I can not really verify that as we can not edit set upload settings), but if this were the case I would like each member to user there own site username and password rather then having to set it to a default one via uniadmin.

Thanks Ihunath you really are doing a great job with this.