DAZ Studio Pro 4.6.2.118, DIM questions

DavidGBDavidGB Posts: 554
edited December 1969 in Daz Studio Discussion

MBusch said:

As Rogerbee said "Just because this and the DIM exist it doesn't mean that you HAVE to use them.". I would ask: why not? I use DIM all the time to install and update my products. It works like a charm.

I don't use it for a simple reason: it requires a folder and files in and therefore access to the Public Documents folder, and nothing on my system is allowed access to the Public Documents folder. The DIM should not REQUIRE that location (especially for things that should go in App data); it should be user configurable. In fact I noticed that in the DIM log files on each running it reports setting that location, which implies to me it OUGHT to be configurable - if it's hard coded with no facility for a choice why is the log showing it? But the option for the user to configure it has either been disabled or hidden. Until and unless DIM does not require access to Public Documents it will never be used on my system.

The CMS is another amazing DS feature that is sub estimated by so much users.

I don't use it and the Smart Content pane for the same reason I didn't when it first appeared. The vast majority of my content, collected since 2004, is not from DAZ and has no metadata, so doesn't show up in Smart Content. Manually creating all that metadata is well beyond my abilities. I'm disabled and can only use the computer for short periods of time - manually metadata-ing my content is a completely impossible and inconceivable task for me. Even if I was still healthy and could use the computer as I used to, the task would still be too vast and tedious to contemplate. So, I use content library and a folder structure in which I can find all of my content, rather than Smart Content in which I can only find a fraction of it.

To DAZ ... when you've fixed the problem with the toolbar, you really must make it available in installer form. Don't just make it a DIM only release as a beta.

On a positive note this is the first DS4.anything update version since the first private betas which has installed for me in one go without error messages and requiring me to manually monkey with files before managing a completed installation. Then again, I haven't run it yet ...

«1

Comments

  • DavidGBDavidGB Posts: 554
    edited December 1969

    MBusch said:
    DavidGB said:
    MBusch said:

    As Rogerbee said "Just because this and the DIM exist it doesn't mean that you HAVE to use them.". I would ask: why not? I use DIM all the time to install and update my products. It works like a charm.

    I don't use it for a simple reason: it requires a folder and files in and therefore access to the Public Documents folder, and nothing on my system is allowed access to the Public Documents folder. The DIM should not REQUIRE that location (especially for things that should go in App data); it should be user configurable. In fact I noticed that in the DIM log files on each running it reports setting that location, which implies to me it OUGHT to be configurable - if it's hard coded with no facility for a choice why is the log showing it? But the option for the user to configure it has either been disabled or hidden. Until and unless DIM does not require access to Public Documents it will never be used on my system.

    Hi David, before all, you are one of my heroes in the community and I have so much respect for your opinion, but I think sometimes we stand hard in a complaint or in a point of view, and forget what for. While I agree that the Public folder in Windows and its counterpart, the Shared folder on OS X, are not the best place to hold the DIM configuration files, as you can configure where the package install files are downloaded, I cannot see this as an obstacle to use DIM.

    Nothing has access to the Public Documents folder on my machine (or the other Public folders), as part - and only one part - of an integrated and designed overall security/protection strategy. All access, read and write, is blocked and locked. Nothing to do with DAZ; everything to do with the way I choose to protect the security of my system. Using DIM as it is and has been would require me to remove that general block. I will not do so. It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Captura_de_Tela_2014-02-11_às_21.56__.05__.png
    238 x 836 - 92K
    Captura_de_Tela_2014-02-11_às_22.13__.04__.png
    112 x 500 - 41K
    Captura_de_Tela_2014-02-13_às_1.46_.46_.png
    559 x 1142 - 161K
    mosx_fs_layout.jpg
    351 x 627 - 56K
  • MBuschMBusch Posts: 533
    edited December 1969

    mjc1016 said:
    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.

  • DavidGBDavidGB Posts: 554
    edited December 1969

    MBusch said:
    mjc1016 said:
    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.While we all think of the term "Content" differently than the rest of the world because of the software we use, Content does not just mean Victoria 6 and everything she wears, her hair and all her friends. Filters and Manifests are generally considered content, settings may or may not be content.

    Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.

    I am not saying manifests should be in appdata - documents is fine, But not having to be in specifically Public Documents any more than My DAZ Library. You should not be trying to force things to be installed as shared content. It's up to the user what should be shared and what not. Poser recommends Public Documents for the main runtime, but doesn't force it, which is correct behaviour. You do the same with the My DAZ Library. What possible reason/excuse do you have for forcing these DIM files into Public Documents rather than allowing the user options, as with the MY DAZ Library?

    Anyway, there are good reasons why a user such as myself might choose to disable the public folders, and it is not for you to say I must trash my carefully chosen and configured system setup just for you. I have many, many other programs from a wide variety of sources, and not one of them forces use of the Public folders, although many will use them if the user wishes, and a fair few will use them by default unless the user chooses otherwise. I choose otherwise. And the authors of the operating system say this is one of the places they CAN be, not SHOULD, and definitely not MUST.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    DavidGB said:
    MBusch said:
    mjc1016 said:
    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.

    While we all think of the term "Content" differently than the rest of the world because of the software we use, Content does not just mean Victoria 6 and everything she wears, her hair and all her friends. Filters and Manifests are generally considered content, settings may or may not be content.

    Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.

    I am not saying manifests should be in appdata - documents is fine, But not having to be in specifically Public Documents any more than My DAZ Library. You should not be trying to force things to be installed as shared content. It's up to the user what should be shared and what not. Poser recommends Public Documents for the main runtime, but doesn't force it, which is correct behaviour. You do the same with the My DAZ Library. What possible reason/excuse do you have for forcing these DIM files into Public Documents rather than allowing the user options, as with the MY DAZ Library?

    Anyway, there are good reasons why a user such as myself might choose to disable the public folders, and it is not for you to say I must trash my carefully chosen and configured system setup just for you. I have many, many other programs from a wide variety of sources, and not one of them forces use of the Public folders, although many will use them if the user wishes, and a fair few will use them by default unless the user chooses otherwise. I choose otherwise. And the authors of the operating system say this is one of the places they CAN be, not SHOULD, and definitely not MUST.That is where Microsoft says they belong, since they are intended to be used by all users of the computer.

  • PixolygonPixolygon Posts: 5,986
    edited February 2014

    o_O

    I didn't even know there was anything under Public Documents. I never use it. lol

    Maybe add in a "install for all users or just this user" option upon installation?

    Found some empty folders and game saves though. lol

    Post edited by Pixolygon on
  • MBuschMBusch Posts: 533
    edited December 1969

    MBusch said:
    mjc1016 said:
    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.

    While we all think of the term "Content" differently than the rest of the world because of the software we use, Content does not just mean Victoria 6 and everything she wears, her hair and all her friends. Filters and Manifests are generally considered content, settings may or may not be content.

    Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.

    From the "File System Programming Guide" at Mac Developer Library:
    Domains Determine the Placement of Files
    In OS X, the file system is divided into multiple domains, which separate files and resources based on their intended usage. This separation provides simplicity for the user, who only needs to worry about a specific subset of files. Arranging files by domain also lets the system apply blanket access privileges to files in that domain, preventing unauthorized users from changing files intentionally or inadvertently.

    The user domain contains resources specific to the users who log in to the system. Although it technically encompasses all users, this domain reflects only the home directory of the current user at runtime. User home directories can reside on the computer’s boot volume (in the /Users directory) or on a network volume. Each user (regardless of privileges) has access to and control over the files in his or her own home directory.

    The local domain contains resources such as apps that are local to the current computer and shared among all users of that computer. The local domain does not correspond to a single physical directory, but instead consists of several directories on the local boot (and root) volume. This domain is typically managed by the system, but users with administrative privileges may add, remove, or modify items in this domain.

    The network domain contains resources such as apps and documents that are shared among all users of a local area network. Items in this domain are typically located on network file servers and are under the control of a network administrator.

    The system domain contains the system software installed by Apple. The resources in the system domain are required by the system to run. Users cannot add, remove, or alter items in this domain.
    Figure 1-2 shows how the local, system, and user domains map to the local file system of an OS X installation. (The network domain is not shown but is similar in many ways to the local domain.) This figure shows the visible directories that the user might see. Depending on the user’s system, other directories may be visible or some of the ones shown here may be hidden.

    OS X Library Directory Details

    The Library directories are where the system and your code store all of their related data and resources. In OS X, this directory can contain many different subdirectories, most of which are created automatically by the system. In iOS, the app installer creates only a few subdirectories in ~/Library (such as Caches and Preferences) and your app is responsible for creating all others.

    Table A-1 lists some of the common subdirectories you might find in a Library directory in OS X along with the types of files that belong there. You should always use these directories for their intended purposes. For information about the directories your app should be using the most, see “The Library Directory Stores App-Specific Files.”

    Table A-1 Subdirectories of the Library directory
    Subdirectory: Application Support
    Directory contents: Contains all app-specific data and support files. These are the files that your app creates and manages on behalf of the user and can include files that contain user data.

    So my argument is that filters, manifests, and settings are not user files, but they are app managed files. They are created and modified by Install Manager, not by the user, even so they are result from user interaction, the file's content is not a user creation. I think the Install Manager folder would be better making company to the Content Management Service folder located at /Library/Application Support. I really can see a solid argument to be where it is.

    DS and DAZ are not the single developer putting this kind of stuff in the Shared folder as you will can see on the screenshot below, someones at last put them on a non documented /Library/Application Support, but this does not make sense at all. My DAZ Content folder, as it shows in the screenshot, was always on the Shared folder by a personal choice and pre dates DAZ Install Manager existence.

    Anyway, I can live with this and I much prefer to ask again for visible icons on Mac menus (see the screenshots). In DS for Windows you get the icons in menu so much visible than in the DS for Mac. The icons in the menu are clearly visible in the Windows version, and so pale in the menu for the Mac version. I would like to get visible icons in the Mac version. They would be as the Look At My Hair icon. What do you think? It is just an aesthetic and cosmetic complaint, but DS users are visual thinkers. Do you think this request make sense?

  • KeryaKerya Posts: 9,511
    edited December 1969

    Vaskania said:
    o_O

    I didn't even know there was anything under Public Documents. I never use it. lol

    Maybe add in a "install for all users or just this user" option upon installation?

    Found some empty folders and game saves though. lol

    That stupid "Public Documents" folder is on C: ... my C: drive is an ssd - do you want to know my opinion about things that insist on being installed on C:?
    If you want to, just imagine very bad words.
    The only option is creating Symlinks
    http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
    Vewy funny - or not.

  • PixolygonPixolygon Posts: 5,986
    edited February 2014

    My C: is an SSD as well and I prefer to keep it to just the OS, drivers, and security software (for scanning speed). I even took it as far as completely remapping My Documents on the OS level to be a folder on E:. I'm not too worried about it being in there as my appdata is still on C: too. For now I'll just look at it as appdata in a crappy location. lol

    Right now, I've only got 1 symlink going, and that's Bryce content. I pulled it out of the program folder and put it on F: where the rest of my libraries are.

    Post edited by Pixolygon on
  • RogerbeeRogerbee Posts: 4,460
    edited February 2014

    DavidGB said:

    I don't use it and the Smart Content pane for the same reason I didn't when it first appeared. The vast majority of my content, collected since 2004, is not from DAZ and has no metadata, so doesn't show up in Smart Content. Manually creating all that metadata is well beyond my abilities. I'm disabled and can only use the computer for short periods of time - manually metadata-ing my content is a completely impossible and inconceivable task for me. Even if I was still healthy and could use the computer as I used to, the task would still be too vast and tedious to contemplate. So, I use content library and a folder structure in which I can find all of my content, rather than Smart Content in which I can only find a fraction of it.

    ...

    Hmm,

    The whole 'no metadata' thing is a good point, and one I hadn't actually thought of. Quite a chunk of my runtime is characters and clothing that have come from Renderosity and were made for Poser, so, as you rightly say, they won't have metadata. So, in that respect alone, there's not much point in me using Smart Content, as I really don't have that much smart content!

    This is why you're always good to have around!

    CHEERS!

    Post edited by Rogerbee on
  • DavidGBDavidGB Posts: 554
    edited December 1969

    That is where Microsoft says they belong, since they are intended to be used by all users of the computer.

    You are missing the point. Obviously I have not explained myself properly.

    Installing on our systems there are two different situations amongst your customers/users.

    1) Installing on a system for multiple users with multiple user accounts where the software is to be used by all. In this case it is quite right and even expected for you to use Public Documents - that's what it's for (leaving aside the question of whether it is really application data or content). Although even in this circumstance allowances should be made for those who do not wish such data files to be stored on their C drive but haven't gone through redirecting Public Documents to another drive.

    2) A system for a single user with a single user account. The default documents folder to use in this case is My Documents, not Public. And a user with a computer personal to them, which no-one else uses, with absolutely no requirement for sharing files between accounts, may have one or more of a number of perfectly valid reasons for not wanting anything to use or even potentially have access to the Public folders, from simple neatness/anti-sprawl/simplicity - not having to remember yet another location things might be when looking for them or to have to keep an eye on - right through to being part of an integrated security strategy giving a higher level of security than is possible on a multi-account system due to the simple nature of having multiple accounts.

    I have installed and used many hundreds of programs/applications on Windows 7 and previously XP. Quiet a few of them had a requirement, if being installed for use by multiple users on a multiple user system, to use locations like Public Documents. But not one of them - NOT ONE OF THEM - forced it. All of them either gave an 'Install for All users/Install for single user' choice during installation - creating a directory in Public if 'ALL', and in My if 'Single'; or they simply gave a user selection of directory to create the folder in, perhaps with a default of 'Public' showing and used if the user doesn't change it. (Oh yes - quite a long time ago, there were a couple, produced by spotty teens in bedrooms who simply instructed what to edit in what .ini file to use a different directory; but they were the exception, and even then they did still provide the means to choose, if clumsily.) Not one - NOT ONE - forced use of Public Documents on Single user systems.

    And that is the point here. You have users installing to multi-user systems, and users installing to single user systems. It's OK, fine and expected for you to follow normal practice for installation for use on a multi-user system. But it is running against best, normal and expected practice for you NOT to allow for people installing on single user systems. And on single user systems you cannot and should not assume you can have access to use Public Documents. That you do is completely appalling, and indeed baffling. OK forgetting initially I suppose, though as a professional company, not a teenager in a bedroom it's surprising. But after the first public release you were called on this by a bunch of people, amongst whom I was only one. And the fact that you haven't fixed the software, despite a number of further releases, to follow normal, never mind best and expected practice for installation on single user, single user-account systems is just incomprehensible. I can only think of two possible reasons, and neither are very flattering to DAZ.

    So the point is that there are different requirements and standards when designing software to install on multi-user machines and single-user machines. DIM is currently designed for multi-user machines, but that does not mean it is OK for single user machines, or that you can ignore single user machines and the requirements of their users - you need to allow for that, and have signally failed to do so. It's not impossible; it's not even hard. Everyone else from big companies to teenager-bedroom-freeware manages to do it; YOU manage it with DS and the rest of your software, so why the heck can't you pull your finger out and get it adapted to meet the standards for single users and their varying needs as well as multi-user setups.

    Now -

    I am a single user with a single user machine, and I will not install DIM because it does not work on my machine - because it has not been designed to the standards for single user use, and requires access to a location it has no right to expect access to from a single user in a single user environment and does not use the location the standards for single user use dictate. Unless you are saying that DIM is ONLY for multi-user environments - in which case it should be clearly stated that that is the case on the product info pages on the DAZ website. Otherwise - SORT IT OUT ACCORDING TO THE STANDARDS FOR SINGLE USER INSTALLATIONS. It's not hard. Everybody else manages it; and even DAZ has managed it with their other software.

    Just on the is it or isn't it application data question - really you should not try saying that the stuff in there is actually content, not application data when the DIM program ITSELF, on starting, writes in its log.txt file:

    Application Data:
    Location = C:/Users/Public/Documents/DAZ 3D/InstallManager

    So clearly DAZ DOES think it is application data. And therefore a breaking of programming standards. But I would agree that SOME of it is not really application data, so you really ought to move the actual application data to where it should be, and have the program internally call the location for the manifests etc something else. But I'm not that bothered by that. I AM extremely bothered by the continual failure to abide by standards for single user use when installed on a single user system. And as nothing on my system has access to Public Documents (or the other Public folders), which is a perfectly reasonable state for a single user system, configured for very good reasons, I cannot run DIM.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    DavidGB said:
    That is where Microsoft says they belong, since they are intended to be used by all users of the computer.

    You are missing the point. Obviously I have not explained myself properly.

    I understand your point entirely. The point you appear to be missing is Microsoft says that is where the files belong on Windows, so that is where they are installed.

    If you believe Microsoft "best practices" are a security problem, that is between you and Microsoft. Unless/until Microsoft agrees with you that it is a Security Risk, and advises programmers change where things are installed, they will continue to be installed where Microsoft says they belong.

  • RAMWolffRAMWolff Posts: 9,026
    edited December 1969

    Gotta agree with David on this one Spooky. MS is assuming there are multiple users on any given computer but most of us, that I know, have our own and if it makes your user base uncomfortable having stuff installed into the Public folder set up then you might want to offer an option like many other installers do.... "Just you" where most stuff will be installed to My Documents or "Everyone" where the content and other needed files will be installed to the Public folders.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited February 2014

    RAMWolff said:
    Gotta agree with David on this one Spooky. MS is assuming there are multiple users on any given computer but most of us, that I know, have our own and if it makes your user base uncomfortable having stuff installed into the Public folder set up then you might want to offer an option like many other installers do.... "Just you" where most stuff will be installed to My Documents or "Everyone" where the content and other needed files will be installed to the Public folders.
    Microsoft also says there should be, for security reasons, two users, minimum, on a computer. The User account and the Admin account should not be the same.

    And as already pointed out "Public" is only shared by users on the Machine, regardless of the number of users onthe machine, even if that number is only 1 unless the System Administrator says otherwise.

    Post edited by DAZ_Spooky on
  • RAMWolffRAMWolff Posts: 9,026
    edited December 1969

    That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    RAMWolff said:
    That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL
    I did not say they mandate, but it is their recommended best practices.
  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    RAMWolff said:
    That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL
    I did not say they mandate, but it is their recommended best practices.

    And if 99.99% of the users don't know/care...it's effectively a mandate, anyway.

    Because, most users never deviate from the defaults (even those that know better...like the fact that one of the reasons for the Target data swipe was a DEFAULT PASSWORD!!!)...so, in essence, the 'suggestion' becomes the 'mandate'.

    And in the end, does it really matter, whether or not there is a locked down User account and an Admin account...because, it seems that the malware STILL has access and gets installed, anyway.

  • MBuschMBusch Posts: 533
    edited February 2014

    DavidGB said:
    MBusch said:
    mjc1016 said:
    DavidGB said:
    It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.

    Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.

    Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.

    While we all think of the term "Content" differently than the rest of the world because of the software we use, Content does not just mean Victoria 6 and everything she wears, her hair and all her friends. Filters and Manifests are generally considered content, settings may or may not be content.

    Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.

    I am not saying manifests should be in appdata - documents is fine, But not having to be in specifically Public Documents any more than My DAZ Library. You should not be trying to force things to be installed as shared content. It's up to the user what should be shared and what not. Poser recommends Public Documents for the main runtime, but doesn't force it, which is correct behaviour. You do the same with the My DAZ Library. What possible reason/excuse do you have for forcing these DIM files into Public Documents rather than allowing the user options, as with the MY DAZ Library?

    Anyway, there are good reasons why a user such as myself might choose to disable the public folders, and it is not for you to say I must trash my carefully chosen and configured system setup just for you. I have many, many other programs from a wide variety of sources, and not one of them forces use of the Public folders, although many will use them if the user wishes, and a fair few will use them by default unless the user chooses otherwise. I choose otherwise. And the authors of the operating system say this is one of the places they CAN be, not SHOULD, and definitely not MUST.

    That is where Microsoft says they belong, since they are intended to be used by all users of the computer.

    Maybe something has changed. From Certification requirements for Windows desktop apps:

    Document version: 3.1
    Document date: June 18, 2013
    This document contains the technical requirements and eligibility qualifications that a desktop app must meet in order to participate in the Windows 8.1 Desktop App Certification Program. For Windows 7, this program was known as the Windows Software Logo Program.

    10. Apps must install to the correct folders by default

    Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user

    10.1 Your app must be installed in the Program Files folder by default
    For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.

    ...

    10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData

    10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\AppData

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Post edited by MBusch on
  • KeryaKerya Posts: 9,511
    edited February 2014

    RAMWolff said:
    That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL
    I did not say they mandate, but it is their recommended best practices.

    Best practices for whom?
    Are you doing everything MS says?
    Good luck with that.
    Because if I left my Windows7 in the Default as Microsoft wants to install it, my SSD would die fast.
    That is why there are a lot of pages on the internet how to configure Windows for an SSD harddrive.
    This is just one example why Microsoft is not always right.

    Personally, I want a CHOICE.
    Make it default, but give me a choice.

    Post edited by Kerya on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited February 2014

    MBusch said:

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)

    That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place. (Also note that Public Documents is easier to remap than appdata.)

    Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.

    Post edited by DAZ_Spooky on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Kerya said:
    RAMWolff said:
    That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL
    I did not say they mandate, but it is their recommended best practices.

    Best practices for whom?
    Are you doing everything MS says?
    Good luck with that.
    Because if I left my Windows7 in the Default as Microsoft wants to install it, my SSD would die fast.
    That is why there are a lot of pages on the internet how to configure Windows for an SSD harddrive.
    This is just one example why Microsoft is not always right.

    Personally, I want a CHOICE.
    Make it default, but give me a choice.

    You have a choice. Public Documents is not required, by the OS, to be on C.

  • KeryaKerya Posts: 9,511
    edited February 2014

    Edited for crossposting ...

    Post edited by Kerya on
  • jestmartjestmart Posts: 3,709
    edited December 1969

    while maintaining the option to install an app in the location of their choice.

    This is the part DAZ doesn't seem to get, some of us users are control freaks that want our computers set up a certain way. I have never installed programs to the Program Files folder when I can help it. I've finally got CMS and its database to run reliably by not putting in its default install location. And with many new computers having SSD OS drives being able to control where files and folder are located is even more important.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Kerya said:
    Spooky: please, please, please - could you give us a choice?
    I KNOW what I am doing at my computer - I don't need somebody to tell me that MS way is the only way.
    Please?
    Or is that technically impossible for you?
    I did not tell you that the MS way is the only way. Like I said, if you don't like where the Public Document folder is by default remap it. Since you know what you are doing on your computer, then you know that is the simplest way to make things work for you. It is also the simplest way for us to make things work and provide support for people that don't know what they are doing on their computer while, at the same time following Microsoft's best practices, which means we don't have to do a major rewrite the next time the OS is updated.
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited February 2014

    jestmart said:
    while maintaining the option to install an app in the location of their choice.

    This is the part DAZ doesn't seem to get, some of us users are control freaks that want our computers set up a certain way. I have never installed programs to the Program Files folder when I can help it. I've finally got CMS and its database to run reliably by not putting in its default install location. And with many new computers having SSD OS drives being able to control where files and folder are located is even more important.Note you can install the app to the location of your choice.

    We get it, we deal with customer service issues on a daily basis because someone decided to install something someplace where it can't work.

    More commonly, what they have is installed all over the place in an inconsistent manner, and it is our software that is "broken" because they don't know what they did or where they installed it.

    Putting it, consistently, where we put it, is easy to remap if you need, or even just want, it on a different drive, without the potential of breaking everything when something changes.

    Post edited by DAZ_Spooky on
  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Kerya said:
    Spooky: please, please, please - could you give us a choice?
    I KNOW what I am doing at my computer - I don't need somebody to tell me that MS way is the only way.
    Please?
    Or is that technically impossible for you?
    I did not tell you that the MS way is the only way. Like I said, if you don't like where the Public Document folder is by default remap it. Since you know what you are doing on your computer, then you know that is the simplest way to make things work for you. It is also the simplest way for us to make things work and provide support for people that don't know what they are doing on their computer while, at the same time following Microsoft's best practices, which means we don't have to do a major rewrite the next time the OS is updated.

    And I think, that is were the 'problem' lies...it's the simple fact that 99% of the computer users don't know enough to make those choices, so what is a developer to do?

    Cater to that less than one percent that does know and is able to make it work the way they want...at the expense of the rest of the users who would find it nearly impossible to do anything and give up in frustration (that's the main problem Linux faced for years)?

    Face it, in order for software to be successful, it MUST cater/be usable by the least capable users, with minimal fuss...so that usually means doing things entirely opposite of what a knowledgeable/capable user would do...and even that is often restricted by illogical (to many) OS imposed 'guidelines'.

    Yes, I agree that having a 'single user' install would be a nice option, that would allow something that now takes a lot of configuring, both at the OS and program level to achieve, but it probably won't be used except by a handful of folks and be very likely to confuse/frustrate/cause problems for the masses. So is it worth the time/effort/expense?

    How many ran the old BitRock installers from the command line...with options?

  • MBuschMBusch Posts: 533
    edited February 2014

    MBusch said:

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)

    That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place.

    Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.


    I quoted 2 documents, 1 from Apple and 1 from Microsoft, and none of them make any mention to store app data on the Shared folder in OS X or Public folder on Windows. There are no mention about store data in those folders in both sites. In fact, both developers state similar concepts about user common data and user specific data:

    From the "File System Programming Guide" at Mac Developer Library:

    Domains Determine the Placement of Files
    In OS X, the file system is divided into multiple domains, which separate files and resources based on their intended usage. This separation provides simplicity for the user, who only needs to worry about a specific subset of files. Arranging files by domain also lets the system apply blanket access privileges to files in that domain, preventing unauthorized users from changing files intentionally or inadvertently.

    The user domain contains resources specific to the users who log in to the system. Although it technically encompasses all users, this domain reflects only the home directory of the current user at runtime. User home directories can reside on the computer’s boot volume (in the /Users directory) or on a network volume. Each user (regardless of privileges) has access to and control over the files in his or her own home directory.

    The local domain contains resources such as apps that are local to the current computer and shared among all users of that computer. The local domain does not correspond to a single physical directory, but instead consists of several directories on the local boot (and root) volume. This domain is typically managed by the system, but users with administrative privileges may add, remove, or modify items in this domain.


    10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData

    10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in UsersAppData

    From Certification requirements for Windows desktop apps:

    Document version: 3.1
    Document date: June 18, 2013
    This document contains the technical requirements and eligibility qualifications that a desktop app must meet in order to participate in the Windows 8.1 Desktop App Certification Program. For Windows 7, this program was known as the Windows Software Logo Program.

    10. Apps must install to the correct folders by default

    Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user

    10.1 Your app must be installed in the Program Files folder by default
    For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.

    ...

    10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData

    10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\AppData

    If you stand that your statement above is true, I would ask, why is Studio4 folder in \\Disk\ProgramData\DAZ 3D as they hold user files as Custom layouts?

    I agree, custom filters created by the user are user data, so they can be stored /Users//AppData. The point is that filters and settings are not user documents as a Scene file is, they are just user data generated by the user upon application UI interaction, but they are data not documents. I mean, I cannot move this files from where they are and I cannot open those files to manipulate them. Well, I can if I could understand how to edit XML, but they are not targeted to be modified and re-saved.

    Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)

    Post edited by MBusch on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited February 2014

    MBusch said:
    MBusch said:

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)

    That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place.

    Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.

    I quoted 2 documents, 1 from Apple and 1 from Microsoft, and none of them make any mention to store app data on the Shared folder in OS X or Public folder on Windows. There are no mention about store data in those folders in both sites. In fact, both developers state similar concepts about user common data and user specific data:Yet the quotes are for Application Data, and the data we are discussing is not Application data but user data.

    Post edited by DAZ_Spooky on
  • MBuschMBusch Posts: 533
    edited December 1969

    MBusch said:
    MBusch said:

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)

    That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place.

    Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.

    I quoted 2 documents, 1 from Apple and 1 from Microsoft, and none of them make any mention to store app data on the Shared folder in OS X or Public folder on Windows. There are no mention about store data in those folders in both sites. In fact, both developers state similar concepts about user common data and user specific data:

    Yet the quotes are for Application Data, and the data we are discussing is not Application data but user data.

    I agree, custom filters created by the user are user data, so they can be stored /Users//AppData. The point is that filters and settings are not user documents as a Scene file is, they are just user data generated by the user upon application UI interaction, but they are data not documents. I mean, I cannot move this files from where they are and I cannot open those files to manipulate them. Well, I can if I could understand how to edit XML, but they are not targeted to be modified and re-saved.

    Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)

    So, may I request to have an option to store my user specific app data where I would like?

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    MBusch said:
    MBusch said:
    MBusch said:

    The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.

    Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)

    That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place.

    Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.

    I quoted 2 documents, 1 from Apple and 1 from Microsoft, and none of them make any mention to store app data on the Shared folder in OS X or Public folder on Windows. There are no mention about store data in those folders in both sites. In fact, both developers state similar concepts about user common data and user specific data:

    Yet the quotes are for Application Data, and the data we are discussing is not Application data but user data.

    I agree, custom filters created by the user are user data, so they can be stored /Users//AppData. The point is that filters and settings are not user documents as a Scene file is, they are just user data generated by the user upon application UI interaction, but they are data not documents. I mean, I cannot move this files from where they are and I cannot open those files to manipulate them. Well, I can if I could understand how to edit XML, but they are not targeted to be modified and re-saved.

    Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)

    So, may I request to have an option to store my user specific app data where I would like?

    Again this is not application data.

    You can request whatever you like, that does not mean your request will be granted.

Sign In or Register to comment.