"What do you think of Western Civilization?" Anyway, I hope you get it sorted eventually. swingīut the library listed above can do that, AFAICT. Posted: Wed 10:35 pm Post subject: Re: awt vs. The only thing I can think of is to go through native dialogs which can be extended unlike their java counterparts. The bummer is that, on OS X, the AWT filepicker doesn't do filtering of files based on extensions, while Swing does, so doing things like adding different formats to a "save as" menu won't fly The AWT filepicker is implemented through the real file dialogs of OS X and not some platform-independent abstraction (like Swing). not display the same sidebar as in the finder, have to navigate through Volumes folder for extra hard drives/partitions, etc.). The Swing filepicker is a "platform independent" filepicker and does similar kinds of things like the OOo filepicker (e.g. Jake: Yup, from Java itself you'd need to display the file picker from AWT and not from Swing. Posted: Wed 8:15 pm Post subject: awt vs. Give Ed and I credit: showing a native dialog is trivial.Īnd i couldn't figure out how to do that. If the print dialog was any indication of the work involved, it will take less than a week to implement but we'll spend a good three months chasing down all of the bugs after our first implementation. It is these non-trivial items that are the reason why we have put native filepickers in the low priority category. The problem is that making sure that it does not cause the OOo code to hang and feeding all of OOo's callback functions with data whenever something changes while in the native dialog is what is not trivial. Give Ed and I credit: showing a native dialog is trivial. I assumed that Patrick did something similar with the print scheme, but my non-web programming is not so hot. I can do NWF on my PowerPC machines (which I'll have until they pry them from my cold, dead hands)Įd, does that mean that you have to use AWT and not swing? (i found code for a swing file picker)Īs for the cocoa, now it has been a while, but when I was looking into it, basically you just run a line of code, but I couldn't figure out how to call that (or where to). I'm toying with punting on x86 and letting someone else do the heavy lifting and instead jumping off into NWF for Neo 2.0. The overall Aqua LAF, though, still is a world away. Right now my recommendation is still to go Carbon/Cocoa on the filepicker, but if this offers an easier binding via Java it may be worthwhile. Thus you're left with AWT (which has a *horrid* file picker) or redoing it in Carbon/Cocoa native. The Swing component offers the filtering and such we need for OOo, but the Swing filepicker isn't implemented using native 's implemented in Swing. It is a good reference, though, especially for anyone who's looking at doing the file picker implementation. " whether the duck drinks hot chocolate or coffee is irrelevant." - ovvldc and sardisson in the NeoWiki Pure Java apps (which Neo is not) on Mac OS X already have an Aqua LAF, although I'll admit that library makes the app "more Aqua" than most pure Java apps. OOo (and thus Neo) uses Sun's (Star Division's) own cross-platform widget toolkit, vcl, and the only way to get an Aqua-looking vcl is to use the N*F frameworks (invented by Ed and Dan in Neo/C) and program your own Aqua N*F vcl extensions. This won't help anyone any more than porting gtk or Qt to Mac OS X. The Quaqua Look and Feel (Quaqua) is a user interface library for Java applications which wish to closely adhere to the Apple Human Interface Guidelines for Mac OS X. Posted: Tue 5:05 pm Post subject: NeoOffice GUI NeoOffice :: View topic - NeoOffice GUI NeoOffice GUI NeoOffice announcements have moved to the NeoOffice News website This website is an archive and is no longer active
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |