Posted: Sun Dec 18, 2005 6:55 am Post subject: a native file dialog...
Hello Patrick,
In june 2005, i have asked for the possibility for a native file dialog. The time of charging NeoOffice is not really a problem for our students (between 12 and 15 years old), but the file dialog is actually really a problem. There is a problem of "look" and a problem of language (the name of folders are in english and not in french, so we have to teach, by example, that Desktop means Bureau).
You had answered me that you hope to have this function at the end of 2005. So what are the news, bad or good ?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Dec 18, 2005 10:40 am Post subject:
Well, the native file dialog progress has kind of been sidetracked by the Java 1.4 work...directly needed by the x86 architecture shift for Macs. Java 1.3 isn't available on x86 Macs, so we needed to do this sooner rather than later.
Dan's passed along some info on how he's done the native file dialogs for GTK. While I had some plans for how to do it in Carbon, I haven't revisited how it could be done using Cocoa. Part of the problem is that a number of the file dialogs have custom controls embedded in them (checkboxes, previews, etc.) and file filtering by extensions...the problem is a bit more complex than I initially thought. I'm not sure how GTK/Win file dialogs address this issue.
It's on the list of things to do, but unfortunately the x86 change had to shift all of our priorities. I haven't had a chance to play with NWF at all and instead moved into the fun of gcc4
It's on the list of things to do, but unfortunately the x86 change had to shift all of our priorities. I haven't had a chance to play with NWF at all and instead moved into the fun of gcc4
Well, James wrote that he'd think about it . _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
It's on the list of things to do, but unfortunately the x86 change had to shift all of our priorities. I haven't had a chance to play with NWF at all and instead moved into the fun of gcc4
Well, James wrote that he'd think about it .
I'm just too busy doing builds right now, but I will look at the FP and see what can be done. However, this will not happen before the new year.
For those of you who are curious about Universal Binaries, Pavel's description is excellent. After reading Pavel's blog, hopefully Ed and my past posts on the Mactel porting will make more sense.
To sum up what Ed and I have said in the past, we will not be using Universal Binaries for NeoOffice 2.0. Why? Because a Universal Binaries is really a PowerPC binary and a Mactel binary appended on in the same file. In other words, to ship a Univeral Binary NeoOffice, the size of all the binaries would be roughly twice as big as they are now. Given that the current Neo 1.2 Alpha download is nearly 130 MB in size, a Neo 2.0 Universal Binary could easily exceed 200 MB. This would be a huge (and expensive) waste of precious bandwidth especially since for most users, half of the binary files is never used.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Dec 31, 2005 9:48 pm Post subject:
For those who are more Mac die-hards, this is nothing but a new name for "fat" executables...the kind that had both PowerPC and 680x0 code in them. During the times of limited drive space, most installers either had two versions (680x0 or PPC) and chose automatically or allowed users to chose between their native processor only and a fat binary.
Fat binaries got even worse on OPENSTEP where, in theory, you could have delivered a Sparc, PA-RISC, x86, and 680x0 platform mixed binary.
For most software apps that are delivered electronically, fat doesn't make sense, especially if the software is installed using Installer.app or a custom installer that can choose between teh binary format. What really shoots software installation in the foot is the drag-and-drop off a dimage installation that Apple's preferred for many a thing. In order to make a drag and drop dimage that supports all platforms, the application binary needs to be fat.
Anyway, for larger applications from any manufacturer it makes more sense to deliver separate executables than the combined fat one both for bandwidth/download size considerations as well as disk space limitations. Yes, there are some of us who consider 100-200MB of disk space non-negligable, especially as the operating system grows ever and ever larger. Woe, gone are the days when an 80MB hard drive seemed spacious
Woe, gone are the days when an 80MB hard drive seemed spacious
ed <--- owner of ye old 9GB HD
Every Mac I have owned save my current one had ≤2 GB HDs
Since OOo and thus Neo are apps that are mostly code (as opposed to Cocoa apps, which have equal--or more--resources vs. code, Universal Binaries seem quite wasteful to all involved here....
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
.
