Re: Live Splitview patch
On May 15, 2009, at 10:49 AM, Wolfgang Lux wrote: In order to keep Riccardo happy you might introduce a new user default to switch between live and non-live resize. However, given that the changes appear quite substantial upon a superficial look, I don't know whether this is feasible. I would concur with Wolfgang that, if this behavior is optional, it would best be controlled by a user default rather than by some dynamic test (timing of operations, etc.) Different people have different thresholds of tolerance for "slow" behavior; an automatic test is unlikely to satisfy as many people as a simple choice might. The fastest "PC" I have in service right now is a 200MHz PIII. It is "fast enough" for the few things I use it for, and I don't like generic PC hardware enough to justify the effort or time needed to upgrade it yet. I use my MacBook or Sun workstation for most things. If it were possible to turn this feature off, I would turn it off on both the PC and the Sun (which is a dual-processor Sparc, but only 450MHz, and enormously slower in X than I am comfortable with since I installed Solaris 10 on it). --Robert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
It is still readily available ( for instance, http://www.opencsw.org/packages/libicu ), and is required by common software such as OpenOffice. I remember looking into it a few years ago for my job, when estimating the effort to support non-English languages in our application. --Robert On Jun 15, 2009, at 4:07 AM, Richard Frith-Macdonald wrote: On 15 Jun 2009, at 00:26, Lars Sonchocky-Helldorf wrote: Am 14.06.2009 um 23:10 schrieb Riccardo Mottola: Hi, Dave MacLachlan wrote: Hey there... I'm looking to add NSCalendar and NSLocale to Foundation. I'm happy to implement them, but I was hoping to do it on top of ICU (http://site.icu-project.org/ ). Are we willing to add a dependency on ICU to gnustep? This is a typical dilemma. Usually I am a friend of having the smallest set of dependencies possible. I checked and ICU is for example readily available in gentoo (if not, I would have really worried) but it is not for example available on sunfreeware, this tells me that it is not that widespread. Really? SUN should use it: This link suggests that it ships with solaris 9 and 10 but not 8 or earlier ... http://sunsolve.sun.com/search/document.do?assetkey=1-66-233922-1http://sunsolve.sun.com/search/document.do ?assetkey=1-66-233922-1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
Riccardo, I would concur, but IIRC from when I looked at it a couple of years ago, there is basically a pure C API and a C++ API side-by-side. The C API lacks an interface to the complex text layout engine, which wouldn't be needed for Locale support. I am pretty sure I got it to build without C++. --Robert On Jun 15, 2009, at 1:45 PM, Riccardo Mottola wrote: Hi Dave, Dave MacLachlan wrote: Hey there... I'm looking to add NSCalendar and NSLocale to Foundation. I'm happy to implement them, but I was hoping to do it on top of ICU (http://site.icu-project.org/ ). Are we willing to add a dependency on ICU to gnustep? The ICU license is GNU GPL compatible... http://userguide.icu-project.org/icufaq#TOC-How-is-the-ICU-licensed- Or perhaps I should be looking somewhere else? From a glance at what dependencies debian lists for that package that it requires C++. I would really dislike to have a hard dependency on something which requires C++. http://packages.debian.org/lenny/libicu38 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
Ouch. That is good to know. We ended up not doing the localization work anyway. The customer wanting it didn't want to fund it. We have no C++ code, but tons of C code (some around 30 years old) which would need this if the idea ever comes 'round again. --Robert On Jun 15, 2009, at 4:13 PM, Pete French wrote: I would concur, but IIRC from when I looked at it a couple of years ago, there is basically a pure C API and a C++ API side-by-side. The Just to save you some time, don't use the C API, as it doesnt work properly. I went through this a couple of weeks ago. Did a C version, got odd results, and ended up recoding the lot in C++ with C wrappers to interface to Obj-C. That works a lot better (much as I hate C++) I was doing transliterations, so I have no idea if the C API would work ffor other things, but my experinece was that it wasn't any good. Subtle wrong results, the worst kind of bug! -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Fwd: Re: GNUstep and Linux Fund]
On Nov 12, 2009, at 12:00 PM, Richard Frith-Macdonald wrote: On 12 Nov 2009, at 16:55, David Chisnall wrote: On 12 Nov 2009, at 16:49, hansfba...@googlemail.com wrote: This allows to display any menu (set via setMenu:) as the popup menu of the view. It is up to the application programmer to use or ignore this feature. Thanks for the explanation. I supposed so. So the issue is rather the default behavior; I would suggest rather do nothing on right mouse click, since that is how things work in all OSes I know of. (And the app menu is visible all the time anyway...) This might make sense if you are in using the Windows or Mac interface styles, but I don't really like it. I think only in windows style ... since the GNUstep behavior is already the same as on a Mac. Having the main menu a single click away without having to move the mouse is a good design from the point of view of usability. A menu that appears where the mouse is beats both a menu attached to the window and a menu attached to the screen in Fitts' Law terms. Yes, the current behavior is a good thing. I actually wouldn't want it to change even when using the windows interface style, since I can see no benefit to *not* providing any action in response to a right mouse click. I would also point out that it is frustrating when the context menu on an OS X application doesn't also contain all of the actions that make sense in that context, such as not providing a 'Services' menu item. There's nothing more frustrating than right-clicking and not finding the action you intended to use, then having to navigate to the menu bar to find it, especially on a large screen (or in my case, multi- screen) setup. A corollary is that it is frustrating to find an action *only* in the context menu, which I have seen as well. If all actions are available somewhere on the main menu or from an Inspector panel reachable from there, providing the main menu as a default makes perfect sense, and a custom context menu just becomes an optimization of that. The difference on OS X is that most views tend to have some kind of context menu, while most in GNUstep apps don't. Yes ... it's up to the app programmer. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
