Cool VL Viewer forum

This is *not* a persistent setting (it never was !) and is lost on relog.

Here is some input on the new file picker from a Mac user's point of view.

This comes from a Mac user who likes the Cool VL Viewer very much – I use it for opensim daily, but it also comes from a Mac user who understands Mac OS X through and through. The below is also not any personal criticism of the developer. OK?

First of all technically the new files selector works. You can pick files with it. That's about it.

From a Mac user perspective, it does not work – at all.


Let me start by giving an example DEFAULT LOCATION:
When you start a fresh session and want to upload a file, the file picker opens the location of the file system that is
/Users/username/Library/Application Support/SecondLife

1. This location on the file system is NOT exposed Mac users by the standard user interface unless they know how to expose the ~/Library path. So at the outset they are presented a location where they have no clue where they are at all. Secondly, most users are clueless to what to do to files in ~/Library and will more than often screw up things if you expose it to them. Having a clueless user hack around as a clueless SecondLife user (and we have seen scores of them..) letting them in here is a recipe for lots of additional support.

If they are lucky, they understand that the Level up button is a function to navigate the file system, but they have never, ever seen this before in any Mac applications, simply because that is not how the user interface works at all. To use the user interface presented to them, they have to unlearn everything about picking files they have learned both on OS X and iOS.

If they, in the process, overshoot their /Users/username directory they end up at / (root), something that is also never, ever exposed to a Mac user unless you start a terminal session, which most don't.

2. If they then press the Home button they end up back in /Users/username/Library/Application Support/SecondLife when the expected behavior should be /Users/username


Next, what files are exposed?
OS X use container files for a number of purposes, which are in reality directories where all the components of a file are bundled up in discrete files and subdirectories. Any application has the .app extension on the directory name, so the Cool VL Viewer on OS X is stored in the "Cool VL Viewer.app" directory when seen from the raw file system. A bunch of other "data" type files are store the same way. The new file picker does not shield the user from this at all, simple because it knows nothing about it. The same happens when you try and store these files on Windows based servers or transfer them to Windows; Windows falls flat on it's face and just present them as normal directories.

So in essence you create a venue for the user to mess up for themselves, when in most cases you want to present a simplified world to them.

So, What functions does a Mac user miss with the new file picker?
There are quite a few functions that Mac users will miss, and that is built into the standard system file picker whiteout the developer having to add one single line of extra code, These are:

1. File preview (QuickLook) so the user can check the full file content from the file open dialog before opening it
2. Full search (entire file system indexed) with search filtering
3. Access to favorite locations
4. Access to smart folders (dynamic searches presented as folders)
5. Access to mounted local and networked drives
6. Access to iCloud disk (from system 10.10 to be launched in October)
7. Access to media pickers that present everything that is stored in iTunes or the iPhoto, iMovie, Photos, Music or Movies folder
8. Remembers current directory (if implemented correct) and does not force a user to navigate back to the same directory constantly like the SL viewer wrongly have implemented it.
9. Filtering files by keyword (10.10) or tags (current)

I can see your argument of not wanting to support multiple OS specific portions of the code, but there are some grand pitfalls there, and I will write about it in another post, not to muddle the message too much here.

I can see your argument of not wanting to support multiple OS specific portions of the code, but there are some grand pitfalls there for OS X and I will tell you why:

1. By following Apple's standard user interface guidelines and using their frameworks, they more or less guarantee 100% that your application will work across multiple system generations, but also across processor architectures.

2. Many application developers, like Microsoft and Adobe followed the philosophy of not writing Mac specific code and it has come back to haunt them horrendously over time. Because of this Microsoft is unable to support 64-bit applications for Office for Mac, because they have to rewrite EVERYTHING from scratch to do so. Adobe is in the same pain point. Even the mono-project has not yet shipped a 64-bit version of Mono, not because they cannot compile core mono 64-bit, but all the support and development applications are written in Carbon which was deprecated with system 10.6.8 years ago, and which also the last system version that shipped with a default 32.bit kernel.

3. Linden lab is exactly in the same dodo, but they have the QT framework to wrestle with, and there is no 64-bit QT for the Mac, so it slows down every Mac application developed with it. The reason why Linden lab don't have an iPad viewer yet, is they have to rewrite everything in Objective C or now Swift to even run. Meaning that early decisions on keeping common code in the interface and for handling media keeps them far away from doing business in that market.

Because if this all TPV and Linden Lab's viewer is compiled to 10.6.8 support, to force a 32-bit version because it will not compile as a 64-bit, fast and modern binary. You still see some of these compiled with PowerPC code in addition, shipped in the same binary.

So yes, you can get Mac applications to run by writing to the native Unix BSD system, open source libraries and use deprecated Carbon libraries, but it is like writing for XP. For all I know it might break when 10.10 is out the doors in a couple weeks (I'm gonna test it on the beta build...)

I also understand you don't have your own development environment for OS X and probably not the knowledge about Objective C and the OS X frameworks to be able to navigate them, but on the other hand you can probably piggyback on the LL viewer and the other TPV developers collectively to get it working more elegant than rolling your own that might break the week after tomorrow.

It is also possible to install OS X on a vmware virtual machine and run it there.

Now, to the killing the main thread by keeping the file picker open too long; Singularity has fixed that by putting the file picker on a single thread. No chance of borrowing their code for this purpose?

That's its only purpose, really...

Then why are you the first Mac user to report this, while the new file picker has been released 5 months ago ?... I guess everyone else considers it does work pretty well, after all...

That's the kind of information I was seeking for and the very reason why I opened this thread... 5 months ago... You're a "little" late, but better later than never. Changing the default to ~/Library (or is it /Users/username ?... you already got me confused...) for MacOS-X is easy and will be in next releases, if you can confirm that this is the default directory that should be presented under all MacOS-X versions (else, I'll need a list of standard "home" directories for each MacOS-X version).

I'm confident that even a die-hard Apple-fanatic will have used a PC running Windoze at least once in their life, and will therefore know all that without having to rely on their "luck". Beside, it's just a matter of learning a (pretty standard and straightforward) way to pick files and directories, even if a different one than the way they are used to. At least, when they will run the Cool VL Viewer under another OS (or OS version for Windows, or window manager for Linux), they will be faced with the exact same file picker, which will undoubtedly save them a few neurons since they won't have to deal with yet another different file picker... That argument is two-sided, you see...

You are mistaking what are my intent and my view about what an OS shall do or not... "Hiding things because users are too stupid (or just computer-illiterate)" is not my way of thinking... not at all, much to the contrary !!! The Cool VL Viewer is not a viewer for your 125 years old great-grand-mother or your 5 years old nephew: it's geared at power-users.
So, yes, the file picker does show and will keep showing all the files and directories, with the exception of explicitly hidden ones (files/dirs with H flag under Windows, or files/dirs starting with "." under Linux and, AFAIK, MacOS-X), that too can be shown by ticking the corresponding check box. I don't intend to change this.

These could be added (it's just XUI and some code), but I won't bother, because I hate file pickers that pretend making coffee for you...

I see no reason why you won't be able to access them !!! AFAIK, MacOS-X abides by the POSIX standards, and all mounted drives appear in the file directory tree as just another directory (usually as a sub-directory in /mnt for temporary mounts)...

One of the reasons why I got rid of the OS file picker... See this JIRA as well as the old Skydrive thread in the bug report forum...

It's already the case in my file picker (the default directory is only used the first time, then the directory you actually used is remembered over the session, and there are even different slots for different upload and download contexts (images, meshes, anims, sounds, etc).

Which is pure bullshit. The viewer is a blatant example, since the migration from Carbon to Cocoa involves a huge overhaul of the MacOS-X specific part of LL's native file-picker code, while my XUI-based file-picker involves ZERO change (because it's independent from the OS and OS-specific UI !).

Not replying this babbling/ranting part of your argument, because it got strictly no relation at all with the file-picker...

My XUI-based file-picker just cannot "break the week after tomorrow". AGAIN, it's OS-independent code (but for a few lines dealing with file system specificities in Windows). See by yourself in indra/llui/hbfileselector.* and admire how it is so lean and clean. Then, have a look at the indra/newview/ll(dir|file)picker.* files (plus llfilepicker_mac.* for MacOS-X) in LL's viewer source, and tell me which is cleaner and easier to maintain... and the less likely to "break the week after tomorrow".

I don't have a copy of MacOS-X itself (and won't buy one just for such a purpose) and VMware or VirtualBox are incapable of running an OpenGL application under MacOS-X: there's no 3D driver available for MacOS-X under these virtualizers. Please complain to Apple & Micro$oft for daring to sell their closed-source, bullshitesque OSes, and consider using an Open-Source OS instead...

I implemented threaded file/dir pickers in the Cool VL Viewer for both Linux and Windows long before Singularity (it was back in the days of the mesh code backport); I just could not extend it to MacOS-X because I don't have the know-how for this OS neither a platform to test the code onto.
Singularity also did it in a very dirty way (in the form of a media plugin (!?!) that got all sorts of race condition vulnerabilities, something the XUI-based file picker doesn't have): I'm not going to replace LL's dirty code with Singularity's: they are both just as dirty and OS-dependent. Just like LL's, Singularity's file picker is also vulnerable to parasitic software under Windows as well as to GTK2 and GTK-themes incompatibilities and bugs under Linux, which my XUI-based file-picker is totally immune to.

Now, I will make things clear once and for all: I love the XUI-based file/dir-picker and I won't go back to OS-based ones, ever !

Follow up to:
I found the problem: it's not in the file selector code itself but in LL's code for LLDir_Mac() which initializes the user directory with the same string as the application directory... It just happens that the user home dir was not used so far by LL and is only used by my file selector (so, the bug didn't show before I implemented the XUI file selector). I fixed that for next releases, so you will get the proper user home directory as the default.

OK, very good.

The absolute path of the users's home directory is /Users/username or just ~ if you are logged in as the user with a terminal session. Hence they will find their version of Library at ~/Library but again it is not exposed as default to the users unless they take special action to see it.

/Library is installed on the boot device for all users on the system for system shared items, where also you would find /Library/Application Support for all users on a system.

For network mounted volumes, a Mac user will never see them from inside their home directory if presented from the raw file system (well, actually not any which way you see it.) They are mounted on /Volumes/sharename which is also how iCloud disks will be mounted (and has nothing to do with how Skydrive implemented their stuff as iCloud functionality far exceeds Skydrive.)

Don't look to LL's viewer how to implement a Mac application because it is just a complete hack and NOT how it should be done. Sometimes I am astonished it runs at all, and TPV developers like yourself has done great work to clean up some of the mess.

The reason I say that it might break before you know it is that Apple is in lockdown mode when it comes applications launched from the desktop in that they put stricter and stricter requirements on code-signing and sandboxing to allow applications to run. Something that is both good and bad. The bad part being it raises the barrier for application development, and many struggle with it.

It is also troublesome because you have to install an old version of xcode to compile most viewers, and this version barely runs on OS X 10.9.x (current) and won't run at all on 10.10 which is in market in about 3 weeks. Of course LL will face the same problem so will be interesting to see how they tackle that.

vmware fusion 7 (pro) is able to run OpenGL applications, but they have royally screwed up the OpenGL driver with this version, so any application on any operating system fails to launch. I guess it will be sorted in a few.

Anyway, keep up the good work, and the reason why I never commented on this before was simply I stopped to use Cool VL Viewer when the Mac builds became far and few between. For me, it has been a very good viewer to use on opensim - great actually!

... oh, I also say this as one who have worked in Apple product management, so I am probably more than colored on how things are supposed to behave.

There is strictly no good at all in this kind of "feature", that is actually here for Apple to keep control over the user's choice to run other software than theirs. It's the same kind of reasoning that lead Apple to forbid the use of a normal (non-Apple) charger to recharge their mobile devices (they added a chip and a protocol, something that have normally no room neither any use in a charger, so to forbid recharging in their absence). These are all means to deter users from using other products than their, as well as a way to implement planned obsolescence (to force users to buy the newest Apple product while the device they already own would work just fine for many more years without the planned obsolescence measures).

I see Apple (and Microsoft) as one of the worst evils: I will personally NEVER buy their crippled hardware and software.

So, if they want to break things by implementing more silly nonsensical protocols, they will simply end up with developers stopping to develop for them (and I won't bother trying to make the Cool VL VIewer MacOS-X-compatible: if it keeps running on MacOS-X, then fine, if not, well... too bad for the poor folks who bought Apple's stuff...).

Don't expect me to spend a single cent (or loose my time) on anything to get a MacOS-X system to compile and test it onto...

Well, at least you are not working any more for the Great Evil... so you are half excused... ;-P

Not sure why you see the software as crippled in that it is the only system I concurrently can run multiple operating systems including OS X on, and at the same time have full access to a fully certified Unix. 87% of Mac OS X is open source (it is only Cocoa and Quicktime that isn't) and Apple actually make pretty good contributions to the open source community. http://www.opensource.apple.com

Sandboxing and code signing have in particular kept iOS 100% malware free, which is a good thing for something as personal as a mobile device. On device information encryption on iOS 8 that also Apple cannot decrypt for law enforcement is also a good thing, and Apple don't scoop up and sell every scrap of information about you like Google does. Google is creepy!

Microsoft is THE evil, with Google busily catching up.

You don't need sandboxing if the OS is safe enough in the first place... E.g. Linux.

Now, don't let this thread become a whatever-OS-fanboy thread (and if you want to know my true view about OSes, none are good enough for my standards, and neither are Linux/UNICES): really good OSes never stood a chance against: 1.- Money (Micro$soft, Apple & Co) - 2.- Bad habits and prehistorical concepts (UNICES and also Windows & MacOS-X since they also use most of the crippled POSIX concepts) - 3.- Crippled CPUs (Intel's architecture). When the foundations are crippled you can't build properly atop of them.

For me it is not about fanboyism at all.

Where I come from I am used to that developers make pride in supplying the best possible experience to their users, and taking advantage of the platform specific features that exist where people don't have to unlearn behavior that is consistent across the platform, and can be as productive or immersive as possible.

What has surprised me, and this is not specific to you, starting first and foremost with Linden Labs, is the often almost hostile attitude to Mac users in the SecondLife / opensim community (both user and developers) "where they must be glad there is support at all", when in fact catering to these users who actually are both willing to, and used to pay could reap both financial benefits and help proliferate the platform. These are often very creative users who are content and experience oriented, and wants things to just work (the way they are used to), and not fiddle with technology.

I do understand that many think it is difficult to support these users, as doing it properly requires coding in Objective C, but as I said before, not doing so (refusing to do so) has kept Linden Lab off the iOS platform, and it will be super difficult for them to re-enter unless SecondLife v2.0 is stellar.

Anyway, I look forward to your next update, and as I said before, personally I really like your viewer and appreciate your effort to provide and enhance it!