Re: Filter Services
2012/2/15 Fred Kiefer : > During FOSDEM Richard and I discussed the usage of filter services for image > conversion in gui. This is an old topic and I was always to lazy to > implement it. With Eric's image converter with Ghostscript and Imagemagik > there was finally more than enough reason to do it. It turned out that the > code in NSImageRep to support this was easy to write. Richard just had to > rewrite DO for the filter service, which had been corrupted a few years > back, and things were working. Or rather more or less so. > I used Ink as my test platform and inserted a PS file into a document, > getting its image converted to tiff on the way. It turns out that > NSLayoutManager cannot handle attachments as the last character. I couldn't > find the reason for that up to now. My example service was just a shell > script using Ghostscript, here the problem was that Ghostscript when used > with an output pipe cannot produce correct tiff images readable with > GNUstep. Richard came up with the idea to write into a temporary file and > pipe this back via cat. Next there was a problem converting the black image > that GS produced into RGB, which I managed to track down today. Still there > are tiff images that get displayed correctly as attachments in Ink and > others that wont. > > So apart from these little issues filter services are working now for > images! > > How to test it: > All you need is a filter program and a service .plist. Attached you will > find the ones I am using to test things. You will need to adjust the path to > the gs.sh shell script. > That we use NSTypedFileContentsPboardType:tiff instead of NSTIFFPboardType > is due to a limitation in the code that converts between file types and > pasteboard types. We should fix that or rather move on to UTI. > > The next step would be to write similar support for pasteboard type > filtering and then to add the same code in NSSound and NSMovie. Add a proper > filter service for ImageMagik (this one would not be a shell script but > rather a DO application). And of course to fix all the issues listed above. > > Hope you have fun with filter services, That's super cool :) -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Minimalist GNUstep possible?
On Fri, Jun 18, 2010 at 4:33 AM, David Chisnall wrote: > On 18 Jun 2010, at 10:16, Jonathan Wolf wrote: > >> As a side question that I am sure to be interested in moving into the >> future, is GNUstep planning on supporting mobile architectures, say >> like Android? I would really love to keep using a compiled language >> (like ObjC) on such a platform and be able to take our tools with us >> onto that end, if we ever go there. Has anybody heard of any luck with >> any developers going this route? I did notice that there was some work >> being done on incorporating ObjC into Android, but I'm sure somewhere >> along that path GNUstep is going to be one of the major players. > > I'm not sure about Android specifically, because it uses its > lets-reinvent-the-wheel-and-make-it-square windowing system and doesn't seem > to like people not living inside their slow VM. Mobiles like the N900 are > definitely of interest to us. Supporting Android will probably be easier > once Cairo has been ported, otherwise we'd have to port the back end to use > Skia natively, which is a lot of effort. For a minimal port, we should be > able to use Cairo's OpenGL or image back ends and just write the event > handling code (which is nontrivial, but not a huge amount of work). I agree that it's probably not worth implementing a skia backend, an OpenGL ES 2.0 backend would make a lot more sense (either directly or via Cairo). Note that we do ship an NDK for android, that let you write native code (it's more geared toward implementing bits of your java app in C/C++ than pure native apps, of course). Not sure how difficult or not difficult it would be to get ObjC working with the NDK, but if the runtime is ported on ARM I don't think it would be very hard to do. -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: Deprecating class posing
On Mon, Jan 4, 2010 at 3:20 PM, Fred Kiefer wrote: > Am 02.01.2010 16:22, schrieb David Chisnall: >> Hi Everyone, >> >> With the non-fragile ABI, Apple removed support for class posing. This >> makes sense, because it's no longer possible to guarantee that the class >> has the same ivar layout. >> >> I'm tempted to do the same thing for our non-fragile ABI. This has the >> added advantage that you could then statically export class names as >> linker symbols, which would make class messages a lot faster (you'd no >> longer need to do the lookup each time, and all of the ugly stuff in >> GNUstep where the class pointer is cached could go away). >> >> Any objections? >> > > I never used pose-as in my code and haven't heard a request for it for a > long time. Because of this I definitely wont object that change. > But it is rather the people who use it who should respond here. afaik the main "client" of poseAs is Camaelon (I used it to swap images on the fly) -- but considering the progresses on GSTheme it should be fine to deprecate poseAs. -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
On Thu, Nov 26, 2009 at 10:15 PM, Riccardo Mottola wrote: > David Chisnall wrote: >> >> On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote: >> >>> There are actually three levels of change information ... >>> NEWS ... just the headlines >>> ReleaseNotes ... some more detail >>> ChangeLog ... everything >>> >>> Maybe you are right and we shouldn't bother with NEWS? I'd be interested >>> to know what others think. >> >> I'd be in favour of ditching NEWS and ChangeLog. >> >> ChangeLog has less information, in a less useful format, than the svn logs >> and is a hold-over from CVS not storing repository-wide change information >> sensibly. With svn log, you can get a log of change messages at any >> granularity that you like. If anyone actually cares about ChangeLog then >> they can do 'svn log > ChangeLog' on their local machine. Stuff in the svn >> log can be processed easily, and is easier for people to check than the >> ChangeLog, for example: > > Well, I disagree. > The utility of NEWS is questionable, but ChangeLog should be preserved. Not > only in a ChangeLog I can write more than in a commit and I can group files > and comment on sigle pieces of them, but it is an easy file I can check. > Also, ChangeLog gets released, so it is available in the end-suer release > tarball. I think we should keep the ChangeLog file, but I really don't see the point in NOT generating it automatically. Nothing prevent you to write more detailed commits logs, and it really feels like duplication to me (and you can always forget to modify the ChangeLog...). > ReleaseNotes may contain comments about incompatibilities, deprecations of > methods, upgrade procedures... > NEWS is perhaps more geared towards notable end-user readable things like > new features, big fixes. It is perhaps more useful for an Application than > the library. > > Riccardo > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Some more screenshots of different Gtk+-Themes
On Fri, Nov 6, 2009 at 12:04 AM, Hans Baier wrote: > Human: > > http://stashbox.org/687981/Bildschirmfoto.png > > Clearlooks: > > http://stashbox.org/687982/Bildschirmfoto-1.png > > Neutronium: > > http://stashbox.org/687983/Bildschirmfoto-2.png Very cool :) -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gtk+-based themeing for GNUstep in progress
On Mon, Nov 2, 2009 at 1:39 PM, Hans Baier wrote: > Hi, > > there are already some results, > see this screenshot: > > http://imagebin.org/70147 Very cool! So if I understand well, you are using the Gtk+ theme API to draw the button in a GSTheme subclass ? Or is it just a pixmap "port" of the Gtk+ theme ? > Who is working on GSTheme ATM? > I probably will have some questions/suggestions... Richard did it, I have started working a bit on it too. Cheers, -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Apple open-source Grand Central
FYI http://www.macresearch.org/grand-central-now-open-all http://libdispatch.macosforge.org/post/libdispatch-is-open-source/ (licensed under Apache License Version 2.0) -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
Hi greg, On Mon, May 25, 2009 at 2:38 AM, Gregory Casamento wrote: > I believe the name of this default should be changed to something like > GSSplitViewUsesGhost or something similar. The name it currently > has is a little too generic. this was on purpose -- nstableview is also going to have this, etc. > GC > > On Sunday, May 24, 2009, Riccardo Mottola wrote: >> Hi, >> >>> Submitted in revision 28291, it's doing live resize by default but >>> users can revert back to the old mechanism by doing: >>> defaults write NSGlobalDomain GSUseGhostResize YES >> >> Perfect. SystemPreferences in svn trunk has now the mathiching variable in >> the Defaults panel. >> >> Riccardo >> >> >> >> ___ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> http://lists.gnu.org/mailman/listinfo/gnustep-dev >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > ## GNUstep Chief Maintainer > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell), (301)362-9640 (Home) > -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
On Fri, May 15, 2009 at 5:50 PM, Riccardo Mottola wrote: > Hi, >> I actually wrote the feature on a netbook... >> Personally I think it's the _right_ way -- the xor splitview is imho >> just a hack (and OSX is of course using live resizing). Now, doing >> live resize may expose some slowness in -gui, but instead of fighting >> the messenger we should fix it. >> That being said, it's imho fast enough as it is now. > > That's fine then. I would add it as a global variable to enable/it disable > it. The same way live window resizing should have. > > Even on the mac you can disable several effects (for example with small > tools). This is very useful also for remote display. Under windows, if you > use RDP to access your terminal, depending on the connection, many features > get disabled: shadows under the cursor, funky progressive display menus, > shadows under the menus and so on. All those things have keys in the > registry (which any speed-up software can tweak for you). Our version of the > registry is the defaults system. > Submitted in revision 28291, it's doing live resize by default but users can revert back to the old mechanism by doing: defaults write NSGlobalDomain GSUseGhostResize YES -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Example theme implementation
Very cool ! It should be quite useful, thanks for committing this. -- Nicolas Roard On 20 May 2009, at 14:59, Fred Kiefer wrote: I just added an example theme implementation by Fred Morcos at usr-apps/examples/gui/ExampleTheme/Rhea This shows how to write a very simple theme that overrides just one method. The idea here being to demonstrate how a theme is build and installed. Fred ___ 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: Live Splitview patch
On Thu, May 14, 2009 at 9:49 PM, Riccardo Mottola wrote: > Hmm, > > I prefer not to have them live... it disturbs me. > Besides, 1ghz is slow for a desktop perhaps, but for some netbook it is not. > I actually wrote the feature on a netbook... Personally I think it's the _right_ way -- the xor splitview is imho just a hack (and OSX is of course using live resizing). Now, doing live resize may expose some slowness in -gui, but instead of fighting the messenger we should fix it. That being said, it's imho fast enough as it is now. -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Live Splitview patch
Hi,
I'm ready to commit this patch, but I wanted to give the heads up before...
This basically remove the reverse splitview bar we draw to instead do
live resizing.
It's reasonably fast, tested on slow-ish machines (~1ghz x86 & ppc),
and makes things much nicer from a UI point of view.
Comments before I submit ? :)
--
Nicolas Roard
"I love deadlines. I like the whooshing sound
they make as they fly by." -- Douglas Adams
Index: Source/NSSplitView.m
===
--- Source/NSSplitView.m (revision 28272)
+++ Source/NSSplitView.m (working copy)
@@ -167,8 +167,6 @@
- (void) mouseDown: (NSEvent*)theEvent
{
NSApplication *app = [NSApplication sharedApplication];
- static NSRect oldRect; //only one can be dragged at a time
- static BOOL lit = NO;
NSPoint p, op;
NSEvent *e;
NSRect r, r1, bigRect, vis;
@@ -345,12 +343,8 @@
}
}
- oldRect = NSZeroRect;
- [self lockFocus];
-
[[NSRunLoop currentRunLoop] limitDateForMode: NSEventTrackingRunLoopMode];
- [_dividerColor set];
r.size.width = divHorizontal;
r.size.height = divVertical;
e = [app nextEventMatchingMask: eventMask
@@ -363,12 +357,13 @@
constrainImp = (floatIMP)[_delegate methodForSelector: constrainSel];
}
- // Save the old position
- op = p;
-
// user is moving the knob loop until left mouse up
while ([e type] != NSLeftMouseUp)
{
+
+ // Save the old position
+ op = p;
+
p = [self convertPoint: [e locationInWindow] fromView: nil];
if (delegateConstrains)
{
@@ -410,148 +405,7 @@
r.origin.x = p.x - (divHorizontal/2.);
r.origin.y = NSMinY(vis);
}
- if (NSEqualRects(r, oldRect) == NO)
-{
- NSDebugLLog(@"NSSplitView", @"drawing divider at %...@\n",
- NSStringFromRect(r));
- [_dividerColor set];
-
-
- if (lit == YES)
-{
- if (_isVertical == NO)
-{
- if ((NSMinY(r) > NSMaxY(oldRect))
- || (NSMaxY(r) < NSMinY(oldRect)))
-// the two rects don't intersect
-{
- NSHighlightRect(oldRect);
- NSHighlightRect(r);
-}
- else
-// the two rects intersect
-{
- if (NSMinY(r) > NSMinY(oldRect))
-{
- NSRect onRect, offRect;
- onRect.size.width = r.size.width;
- onRect.origin.x = r.origin.x;
- offRect.size.width = r.size.width;
- offRect.origin.x = r.origin.x;
- offRect.origin.y = NSMinY(oldRect);
- offRect.size.height =
-NSMinY(r) - NSMinY(oldRect);
-
- onRect.origin.y = NSMaxY(oldRect);
- onRect.size.height =
-NSMaxY(r) - NSMaxY(oldRect);
-
- NSHighlightRect(onRect);
- NSHighlightRect(offRect);
-
- //NSLog(@"on : %@", NSStringFromRect(onRect));
- //NSLog(@"off : %@", NSStringFromRect(offRect));
- //NSLog(@"old : %@", NSStringFromRect(oldRect));
- //NSLog(@"r : %@", NSStringFromRect(r));
-}
- else
-{
- NSRect onRect, offRect;
- onRect.size.width = r.size.width;
- onRect.origin.x = r.origin.x;
- offRect.size.width = r.size.width;
- offRect.origin.x = r.origin.x;
-
- offRect.origin.y = NSMaxY(r);
- offRect.size.height =
-NSMaxY(oldRect) - NSMaxY(r);
-
- onRect.origin.y = NSMinY(r);
- onRect.size.height =
-NSMinY(oldRect) - NSMinY(r);
-
- NSHighlightRect(onRect);
- NSHighlightRect(offRect);
-
- //NSLog(@"on : %@", NSStringFromRect(onRect));
- //NSLog(@"off : %@", NSStringFromRect(offRect));
- //NSLog(@"old : %@", NSStringFromRect(oldRect));
- //NSLog(@"r : %@", NSStringFromRect(r));
-}
-}
-}
- else
-{
- if ((NSMinX(r) > NSMaxX(oldRect))
- || (NSMa
Re: Messaging across threads using NSThread
On Mon, Apr 6, 2009 at 11:09 PM, Fred Kiefer wrote: > Nicolas Roard wrote: >> On Mon, Apr 6, 2009 at 8:48 PM, Riccardo Mottola wrote: >>> Hello, >>> >>> in FTP (available in GAP, http://gap.nongnu.org) I do inter-thread messaging >>> with the precise goal to have threads perform operations on the main thread >>> GUI operations. >>> >>> I set up DO between the app itself this way: >> >> I was surprised that you did not mention performSelectorOnMainThread: >> (http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/performSelectorOnMainThread:withObject:waitUntilDone:) >> but it sadly doesn't seem to be implemented on gnustep (I was sure it >> was !?). >> > > > It is there in NSThread.m, most likly you looked in a different place. Ah, thanks ! yes, I only looked in NSObject.m. My bad ! -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Messaging across threads using NSThread
On Mon, Apr 6, 2009 at 8:48 PM, Riccardo Mottola wrote: > Hello, > > in FTP (available in GAP, http://gap.nongnu.org) I do inter-thread messaging > with the precise goal to have threads perform operations on the main thread > GUI operations. > > I set up DO between the app itself this way: I was surprised that you did not mention performSelectorOnMainThread: (http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/performSelectorOnMainThread:withObject:waitUntilDone:) but it sadly doesn't seem to be implemented on gnustep (I was sure it was !?). -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
Hi, On Wed, Feb 4, 2009 at 5:23 PM, Richard Frith-Macdonald wrote: > I'll be leaving for FOSDEM tomorrow morning and won't be home again until > Monday evening. > My availability on email over that period will be very patchy. > Hope to see a few of you there. Well on my side, it looks I may only be able to come the saturday intead of the whole weekend... Would it be possible to swap the Pragmatic Smalltalk presentation from sunday morning to saturday ? Or is there somebody willing to give the talk ? (slides furnished !) Cheers, -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [FOSDEM] Accepted: GNUstep+Etoilé+O penGroupware.org devroom
Hi, On Fri, Dec 5, 2008 at 9:36 AM, Helge Hess wrote: > BTW: I think someone asked about hotels to avoid? :-) > > IMHO it would be a good thing if we would all stay in the same hotel, and > maybe we could get an offer if we book as a group? > > I think the one selected by Nicola last year was quite good: > > http://www.hotel-argus.be/ > > Lars, can you organize that? Any news on the hotel ? -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep and Etoile
Hi fred, On Fri, Nov 21, 2008 at 9:29 AM, Fred Kiefer <[EMAIL PROTECTED]> wrote: > I don' want to make too much fuzz about Etoile people not posting their > new release on the GNUstep mailing lists. Nor about not waiting for the > next GNUstep gui and base release, which is due in a few days and could > even have been brought forward a bit, if requested by Etoile. That's very true. We were delayed by the LLVM release, so what happened is simply that as soon as LLVM made their release we made ours. We should have synchronised with gnustep if the next release was so close. > What is worrying me more than this accidental things is the feeling of a > growing split between our two projects. To start of with a personal > opinion, I think that Etoile is by far the more interesting project. In > GNUstep we only try to reimplement concepts defined by Next and Apple > whereas Etoile seeks to come up with concepts for the future. So I > really understand why you are working on Etoile and not GNUstep, > although I choose differently. > > Now what are the signs I see for a split? > > - Etoile people stopped to contribute to GNUstep (code and bug reports). > This may be due to GNUstep offering everything they need or because they > prefer to fix problems in their own code and keep the changes there. The former is more likely :) > - Etoile not adopting to changes in GNUstep. Here I may be looking on > the wrong source code, but at least in Etoile trunk Camaelon and Wild > Menus ignore many of the changes made to GNUstep drawing code over the > last two years. There may be other areas where the code from the two > projects would need some more integration, but I am most ignorant of > that. (another bad sign) This I believe falls in my garden. Both Camaelon and Wild Menu need to be updated, and I simply haven't had the time to contribute to either etoile or gnustep this past year. Now that I'm free again, I'll resume this work. Others contributors to etoile simply worked on their own parts of the project.. > I think this drifting apart is bad for both projects. It has drained > GNUstep from some of its most active developers and contributes to the > stand still of GNUstep's theming interface. And for Etoile it leads to > problems when users try to install Etoile on a different version of > GNUstep than the one the code was tested with. It also results in users > not getting bug fixes from GNUstep because of Etoile methods overriding > that code not being adjusted. do we have other examples apart from camaelon of things that do that ?.. > What about a shared review of code and concepts in Etoile that proved to > be valuable and of interest in GNUstep and then an effort to incorporate > the relevant parts of that back into GNUstep? Setting up once more a > clean interface between our projects. That'd be great -- what parts are you thinking of ? (yep, camaelon I'd guess) > > I hope to start a productive discussion with that mail and not some > flame war. > Fred No problems. thanks, -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: more licensing issues :(
On Fri, Jun 20, 2008 at 11:40 PM, Gregory John Casamento <[EMAIL PROTECTED]> wrote: > GNUstep has been moved back to GPLv2+ so those licensing issues should be > taken care of. > > I will contact Andrew and see what can be done about this. > > Thank you for pointing this out. > > Later, GC > > Gregory Casamento -- Principal Consultant - OLC, Inc > # GNUstep Chief Maintainer > > > - Original Message > From: Hubert Chathi <[EMAIL PROTECTED]> > To: gnustep-dev@gnu.org > Sent: Friday, June 20, 2008 1:51:51 PM > Subject: more licensing issues :( > > Debian Bug #487143 [1] was filed against gnustep-gui, which points out > that some of the included images are licensed in a way that prevents > modification, and also prevents use for anything other than developing > free OpenStep applications. > > [1] http://bugs.debian.org/487143 > > This presents a problem since Debian requires that everything in the > distribution, including images, sounds, data files, documentation, be > freely modifiable, and so this could result in GNUstep being removed > from Debian. > > I should note that this license only applies to certain images: namely > the images used for drawing various GUI controls such as checkboxes, > etc. > > Is it possible to get these images relicensed? Maybe we could replace those icons by jesse's icons ?.. -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
little fix on autogsdoc
Hi, Is it ok if I apply this little patch ? It simply enclose the methods summary and the abstract in divs, so you can style them. Any reason why the css include line 1119 is disabled ? thanks, -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams AGSHtml.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Google SoC
On Wed, Apr 9, 2008 at 12:45 AM, Nicola Pero <[EMAIL PROTECTED]> wrote: > > > Specifically I am thinking of Richard, who would be the ideal mentor for > > this project. Nicola comes second to my mind, but if none of them would > > take it, I am willing to step in. This is surely the application that > > will need more support. > > I was a mentor last year, but there are a lot of other people who would be > excellent mentors, so I think we should rotate - unless there's > a special reason (eg, we get more students if we have more mentors) > I'll give it a miss this year and let someone else do it. :-) I think that's the case in fact :) so don't hesitate. > Btw I enjoyed it last year because Chris was a good (and very nice) student, > but had a hard time finding the time to follow him properly as I'm > already swamped - like most other people I think - by projects/things to do. > Next time I do it I'll allocate lot more time for it, and I recommend > to everyone who will be a mentor to think about the time it takes in > advance. It's worth it (I look forward to my next mentoring), but > if you want to do a good job with your student, you'll have to follow > him/her very regularly. :-) I think it may be great to try giving more regular feedback on the mailing list this year -- I didn't really track the progresses last year but would have been interested. Something as simple as each student sending an email with a few lines of text every week describing the past week effort and the plan for the coming week would be great (nothing that'd take more than 5 minutes to write, really). -- Nicolas Roard "Java, the best argument for Smalltalk since C++ " -- Frank Winkler ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep Alternative to CGImage
On Mon, Feb 25, 2008 at 9:57 PM, Justin Kendrick <[EMAIL PROTECTED]> wrote: > I'm trying to write an open-source clone of Core Animation to use with > GNUStep. Of course, CA's interface is fairly highly coupled with > Quartz/CoreGraphics, mainly in its use of CGImage to pass image data > in and out. NSImage seems heavier-weight, with its representation > system, but I don't know if NSImageRep is really suitable for that. > Does anyone on the list have more perspective on this? You can create a NSBitmapImageRep from a pointer to a byte array -- hard to think of anything leaner. On the other hand for CoreAnimation, you may be more interested by using Cairo directly ? -- Nicolas Roard "Java, the best argument for Smalltalk since C++ " -- Frank Winkler ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Short report from FOSDEM
On Mon, Feb 25, 2008 at 2:28 PM, Fred Kiefer <[EMAIL PROTECTED]> wrote: > As some of you could not make it to the FOSDEM, I think that those who > did should report to this mailing list about the experience. Somebody > may be able to distill a Wiki entry from these mails. > > Friday evening: > The chosen hotel turned out to be sub standard. Indeed, more than sub standard. So that everybody remembers it, It's the Sun Hotel, 38 rue du Berger, 1050 brussels. Do not go there. Really. One of the worst hotel experience I had in Brussels. > At 9pm only Nikolaus Schaller and me are in the breakfast room, instead > of starting a GNUstep hacking session we install the newest QuantumStep > in my Zaurus and I am quite impressed about the progress that Nikolaus > has made and even more by the amount of hardware he brought along. > Half an hour later two French hackers show up, the name were Daniel and > Mathew if I remember correctly. They hadn't eaten so they went to find > something and come back later, but they never showed up again. Surely > they are from the Etoile group, we regularly loose them :-) > > At about 11pm Gerold and Axel Becker show up. I start to install GNUstep > from SVN on one of Nikolaus micro PCs. On the next day it turns out that > the rest was in a hotel, less than 500 meters away. We really need to > work on our coordination. > > Saturday: > I miss out on all the FOSDEM talks, but have some very nice chats at the > GNUstep stall. > I met Pirmin Braun from seat-1 (www.seat-1.de, in German, sorry). This > company has a GNUstep web based application IntarS, > a very promising ERP solution. They may need some support in GUI > programming later, we will stay in contact. > > Talked to Fabien Vallon about his planed NSGradient and NSShadow > implementation. The former should be rather easy to do with cairo and > for the later he will have to look at groups in cairo and implement a > lot himself. What about the other backends? > > Had a short chat with a guy from the Foresight Linux group blocking > access to our stall for some time. Turns out they are using a very > promising packaging module called Conary > (http://wiki.rpath.com/wiki/Conary), there is a FOSDEM lightning talk on > it on Sunday. The guy claims that this is the future of packaging and > most likely he is right, there must be something better then current > package managers. > > For now we will need something better and in steps Will Stephenson from > Novell/Suse. His aim is to get clean packages for Oolite > (http://oolite-linux.berlios.de/). This is a computer game that goes > back to BBC Elite and it is already in our Wiki > (http://wiki.gnustep.org/index.php/Oolite.app). > To get packages for Oolite Will wants to package up GNUstep itself. > Working for Suse he is quite familiar with the Suse build service > (https://build.opensuse.org/) and has set up initial project for the > GNUstep parts he needs for his toy project. We agreed that I will > register myself at that web site and have a look. If I like what I find, > I may take over his GNUstep packaging projects. The benefit will be that > this not only offers packages for Suse, but for a lot of other > distributions as well. As I understand it, this works mostly by > supplying one description file. We will see what comes from this. > > Most of the rest of the day I was hacking with Richard trying to solve a > problem I have with KeyValueBindings. We failed and I will have to > extract that code to give him a simple example to work on. > > In the evening we all (Richard, Nicola, Gerold, Helge, Lars, Nikolaus, > Valentino, Axel and me) went out to have diner together. We found a very > nice Thai restaurant near Sanct Boniface. On the way there we met > Nicolas Roard, who had just arrived. > > I did not go to FOSDEM on Sunday, so somebody else will have to report > from there. Later that day I met Nicola and Lars at the train station, > so I know that Nicola worked hard on getting Renaissance to work with > newer Apple releases. This is because somebody from OpenOffice wants to > use Renaissance as the basis for a native OO release on MacOSX. Nicolca > will have to provide more details himself. Thanks very much for this interesting report ! Sadly I missed most of fosdem the sunday, as I only arrived around 15:40 (!). I barely had time to talk with the remaining people, then everybody was leaving and we packed the stand.. as far as I could see, having a looping video showing a demo was a great idea, but the big hits were apparently the 'gadgets' running gnustep brought by helge and nikolaus (an openmoko device and a toshiba libretto), which attracted many people :) I took a couple
Re: FYI -- Fwd: [Etoile-dev] Étoilé S pring Hackathon
On Feb 7, 2008 7:27 AM, Sas(o Kiselkov <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Y0 > > Swansea is a bit too far away for me + considering my workload around > school and work I doubt I'll be able to find 4 full days of time... > Sorry guys... :-/ Sorry to hear that... good luck with school ! Are you planning to come to the fosdem ? -- Nicolas Roard "Java, the best argument for Smalltalk since C++ " -- Frank Winkler ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
FYI -- Fwd: [Etoile-dev] Étoilé Spring Hackathon
Hi, It seems the mail didn't pass through, I forward it for david. -- Forwarded message -- From: David Chisnall <[EMAIL PROTECTED]> Date: Feb 5, 2008 4:05 PM Subject: [Etoile-dev] Étoilé Spring Hackathon To: Discussion list for Étoilé desktop environment <[EMAIL PROTECTED]>, Developers list for the Étoilé desktop environment <[EMAIL PROTECTED]> Cc: Discuss-gnustep GNUstep <[EMAIL PROTECTED]> Hi Everyone, The Computer Science Department here in Swansea has agreed to allow us the use of a room for a hackathon over Easter. The date is provisionally the 31st of March to the 3rd of April (let me know if this is a major problem for anyone, and we can try to reschedule). The Swansea University campus is situated a short distance from the city centre, between a park and the sea[1]. There are a few nice pubs (including one with real ale and free WiFi) within walking distance, and some nice scenery to explore when people are bored with staring at screens. There are direct busses and trains from London airports (trains around £25 in advance or very expensive close to the time, bus around £40) and a number of cheap B&Bs within ten-fifteen minutes walk of the campus. Étoilé and GNUstep developers of all levels of experience are welcome. If anyone would be interested in giving a public talk during the hackathon, let me know and I'll organise some publicity. David [1] http://maps.google.co.uk/maps?f=q&hl=en&geocode=&q=swansea+university&ie=UTF8&ll=51.609382,-3.979111&spn=0.029583,0.070038&z=14&om=0 ___ Etoile-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/etoile-dev -- Nicolas Roard "Java, the best argument for Smalltalk since C++ " -- Frank Winkler ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Theming support for NSScroller
On 10/5/07, Günther Noack <[EMAIL PROTECTED]> wrote: > > Hi! > > I understand your point. On the other hand, I'd like to be able to > create themes completely without additional pixmaps, so that drawing > performance stays equal to a non-themed GNUstep. So images are not an > option for me. I do agree; but what needs to be done is different from your patch. > What about this solution: > NSScroller.m and NSScroller.h has a NSScrollerButtonCell and a > NSScrollerKnobCell class which inherit from NSButtonCell. Overriding > their drawRect:inView: methods would provide enough flexibility to > allow both pixmap and programatic theming. Alternatively, these new > cell classes could call specific GSTheme methods to let GSTheme draw. > Something like -drawScrollerKnobInRect:highlighted: and - > drawScrollerButtonInRect:highlighted:, possibly - > drawScrollerKnobSlotInRect: (this can be called from -drawKnobSlot in > NSScroller). I'm not sure how different it is to what camaelon currently does; anyway the approach that makes the most sense to me is to delegate the "background drawing" of widgets to GSTheme methods, but keep all the logic out of GSTheme. Then to implement a theme you just need to provide a new instance of GSTheme; the methods could provide a new look either through new code or through pixmaps. With that approach, Camaelon will stop reimplementing parts of appkit and focus only on beeing a pixmap theme engine, simply done as a GSTheme instance. -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à enlever." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling from Mac OS X
On 9/10/07, Markus Hitter <[EMAIL PROTECTED]> wrote: > > Am 10.09.2007 um 01:38 schrieb Nicolas Roard: > > > Just install X, and that's it. > > This pretty much rules out using GNUstep for a popular Mac OS X > application. It depends _why_ you want GNUstep on OSX... Running GNUstep on OSX via X11.app is *certainly* not the right approach if you want to port a gnustep app on OSX. It is only interesting for a very limited population, mainly developers that want to use the real gnustep without installing linux, either for testing the portability of their app, or to work on gnustep itself using some OSX tools like Shark. > There _was_ a point when GNUstep worked with NeXT/Apple runtime. > GNUstep is a thin layer/extension to Cocoa then. No backend needed, > but source is fully compatible with other GNUstep platforms. Isn't still available ? -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling from Mac OS X
On 9/9/07, Markus Hitter <[EMAIL PROTECTED]> wrote: > > Another problem are the includes of base headers. We use "include" > > here, > > but Apples headers are not protected against multiple inclusion. The > > best solution here would be to replace our includes with "import". > > You'll find a lot of heated discussion about this in the past years > of this list. Get your flame-proof suit handy ;-) > Well, as far as I remember, the problem was that gcc decided to mark #import as deprecated, hence the flamewar on what to do. But unless I'm mistaken, they de-deprecated it :) So I'm not sure why we would have a flamewar now if we decide to clean up things by using #import everywhere. > > how to get the X events from Apple > > GNUstep on top of X on top of Cocoa ... no chance to get the apple- > apple-apple combo back working? a long time ago (2-3 years ?) I had GNUstep compiled on OSX, but using a recompiled gcc, not the apple one; as far as I remember there was problems with the apple-apple-apple combo back then, you had to use the GNU runtime, etc. But apart from this recompiled gcc, nothing special had to be done for the X part... I'm a bit unsure why you'd need anything special in fact ! Just install X, and that's it. -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Need informations about NSAnimation on MacOS
On 3/23/07, Xavier Glattard <[EMAIL PROTECTED]> wrote: Xavier Glattard online.fr> writes: > 2) I dont understand the 3 NSAnimationCurve... An other question : You can change the NSAnimationCurve while an animation is running. Does the animation _smoothly_ changes to the new curve ? Or does it 'jump' ? smooth change, please :) imho the simplest way is probably to use a bezier curve with different control points, and change them smoothly to go from one kind of curve to the other.. -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
On 3/16/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: On 3/16/07, Nicola Pero <[EMAIL PROTECTED]> wrote: > > > But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in > > which we are sorely in need of help. Currently, a Renaissance GUI builder would be > > interesting, but not essential. > > It's kind of an upsetting answer for me, but I'll refrain from submitting it as a project then. While I agree with Gregory that it would be better to support Renaissance in Gorm, for SoC, which only last a summer and depends on student's interest, we should not block the option of Renaissance GUI builder. 1. Duplicate work will become an issue only when there is a student who are interested in it. Yes, definitely. Just add the project for the SoC, if somebody is interested it's good anyway. Although I understand greg -- what we would ideally get from the SoC are areas that we need yet where few are working on it at the moment; SoC or a bounty would be in that case possibly a good incentive for people to work on these. In my opinion, these areas for the moment are the windows port (although Xavier works on it now) which is really needed, the Cairo backend (same here, fred is working on it too, but I'm sure he wouldn't mind help), the printing backend, and in general reducing the gap between gnustep and osx... (in addition to adding/improving classes, bindings looks to me like a very cool project for instance). 2. Even there is a student who is interested in it, Nicola can keep the GUI builder modular in case in the future, GNUstep want to support Renaissance in Gorm. So if this Renaissance GUI builder can be more or less in the similar structure of Gorm, or even use the same interface for bundle, to me, it should be an option for students. Well... having looked at Gorm's code and architecture, I'm not sure why we would need a completely different GUI builder. Gorm is very flexible! for me we could easily: - add a gorm palette dealing with the autoresizing widgets (GS*box) - load/import Renaissance files Actually I'm thinking that a nice addition to Gorm could be, instead of a "new application" menu item, have a panel coming up asking you what kind of "gorm file" you are interested in. In that case you could choose a "Renaissance" project, where you'd have the resize stuff all ready for you, for example. Or we could have even more complex projects (like a steptalk-based project where you'd do all your development *in* gorm; or we could imagine a project showing you a palette of stacks and things like that, eg to have something very close to Hypercard, etc.). Remember: Gorm is not a mere GUI builder, it truly is an object relationship modeller ;-) That probably would benefit on a more customizable/flexible palette browser. -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
On 3/15/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: Nicola Pero wrote: > I looked at the stuff, and the money is pretty good for students -- it looks like > it's 4,500 USD in total for the Summer job ? :-) > > Can we add 'Writing a Renaissance GUI Builder' to the list of tasks ? I volunteer > mentoring a student doing that. It's a pretty tough job though, so only determined > people! ;-) > No, lets not write a new GUI Builder here, but add a plugin to Gorm that is capable of reading and writing Renaissance files and of handling the layout elements. Reading will be fairly easy, it is the writing that is hard as we only want the changed attributes to show up. And if we have a solution for that, I would also like to see that used for keyed value encoding. The only idea I have here is to create a default object of the same class and only write out the attributes that are changed from the default, but event that may be to much information. I'd be more interested by a Gorm palette adding the GS*Box stuff... -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Congratulations, Your organization has been accepted in to the Google Summer of Code(tm) 2007
On 3/15/07, Adam Fedor <[EMAIL PROTECTED]> wrote: Woo Hoo! :-) Excellent news !! :-) I'll probably have time to mentor a student this summer if needed. -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Shipping Windows binary applications
On 3/2/07, Alex Perez <[EMAIL PROTECTED]> wrote: Richard Frith-Macdonald wrote: > > On 28 Feb 2007, at 16:00, Nicola Pero wrote: > >> 1. the alert panel asking you to set your 'Server Preferences' is >> very annoying and very unprofessional. I keep getting it any time I >> change something and it's horrid. :-( > > I *think* it used to open the server preferences panel rather than pop > up an alert panel ... not sure why that's happening. > Also, it should only happen first time ... so if it keeps happening then > there is a bug somewhere. > >> Obviously the default on Windows should be using the Windows taskbar >> and using Windows window >> decorations! > > matter of opinion :-) It shouldn't be. The fact that you even would dare to suggest that you disagree with this honestly really scares me, honestly. Tongue-in-the cheek comment, humour, lighten up ? you know ? -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Etoile live cd 0.2 prerelease
On 2/27/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: I tried to download this file, but Safari complains about a non-existing URL. Could you please reconfirm that the link on this page is correct? Yes, I left the lab in a hurry and forgot to rename the iso file properly... sorry about that ! it should be fixed now :) as a side note: I must stress this is certainly NOT intended as some kind of final live cd release, eg something we want to distribute to as much people as possible and have it advertised on as many news sites as we could: there's simply too many little bugs for it to be a good idea :-) It's simply, as stated, a *pre* release (emphasis on the *pre*), just for étoilé dev and gnustep dev to toy around, have a look, and possibly help us find more bugs than the ones we already know about ! :-P Considering our actual buglist, I think we'll need at least another month if not more (usual delay introduced by real life !) to release the final 0.2; so we thought it was better to put online what we have at the moment, even if rather imperfect, than having people waiting a long time.. it's still a cool iso to try imho :-) Cheers, -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Etoile live cd 0.2 prerelease
Hi everybody, Here's the pre-release of the etoile live cd we made for the fosdem... it's buggy, but it's available to play with ! we expect to fix the bugs and make the final 0.2 release in about a month or so. In the meantime if you download it and find other bugs than the one we already found (check the bugtracker https://gna.org/bugs/?group=etoile) please fill a bug ;-) http://xdev.org/etoile/ Have fun ! -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
FOSDEM
Hi all, Just a quick update about the fosdem... First.. materials.. I printed 50 color copies of the booklet (http://www.roard.com/gnustep/fosdem_a4.pdf) and 50 color copies of the brochure (http://www.roard.com/gnustep/GNUstep-brochure.pdf). In addition, there's a few leftover from last year; I think it should be enough (at worse we can print more in brussels) -- or more exactly I'm pretty sure we'll run out of copies (people like color stuff..), but, considering the small apparent impact those had, I don't know if we should print much more than that (feel free to print some if you want though). I also printed a bigger banner in addition to the small one from last year. We should also have an étoilé livecd available (also with an account setup for "standard" gnustep). Gürkan: did you do an update of your livecd ? For the talks, I'd like to film them -- like last year's attempt.. only better (http://www.xdev.org/fosdem2006) ;-) Normally jesse should be able to bring a video camera, but if you can bring one too, please do it (send me a private mail perhaps) -- it will be better and more flexible if we can have two cameras instead of one, obviously. In the same way, if you have a spare external hard drive with lots of place, that could prove useful for the video. On the booth, we'll have some books available (http://wiki.gnustep.org/index.php?title=FOSDEM_2007#Books_to_Show) for people interested, but more importantly, I'd like us to really make an effort to demo things to people -- not just sitting behind our desk like we usually do... Gerhold is bringing a nice LCD screen, so if you bring a machine with you, try to set it up (perhaps a demo guest account ?) to easily demonstrate gnustep :-) ; ideally we could take turn to do short demonstrations (gnustep environment, project center / manager, gorm, converter demo, Windows port, etc). Again, if you can bring a spare machine with you for the booth, that'd be great -- spare LCD would be great as well. Really, we should try our best to have an interesting booth -- that's what people will see of gnustep. Last thing.. I'll arrive in brussels thursday evening; if somebody wants to meet before the fosdem (quentin and jesse will be there too) just send me a mail. See you in Brussels ! -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Nicolas Roard <[EMAIL PROTECTED]> wrote: Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). And of course I don't think it's really useful to put the alt modifier as it will here all the time ? -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The need for an official GNUstep desktop
On 8/27/06, Sašo Kiselkov <[EMAIL PROTECTED]> wrote:
I'd much rather prefer GNUstep to stay a cross-platform API and
development environment, rather than trying to be a bit of everything.
It would hurt commercial applicability of GNUstep, such as we do at our
company, if I had to deploy tons of other software together with my
GNUstep app. Some for of coordination between a full-blown desktop and
the GNUstep development framework would be nice, of course, but it
should not directly affect GNUstep development. I'd rather see the
relationship between GNUstep and it's "official" desktop be something
like GTK+ or Qt are to all DEs built on it - they are foundations of
them, but is also usable to build stand-alone apps.
I agree. Other reasons are that you'd need to reach an agreement about
what exactly this yet-another-gnustep-desktop project would be, which
in my experience is not that simple ^_^ , particularly if it's
supposed to be the "official one", and also that considering that not
many persons are working on the existing gnustep desktop projects _at
the moment_ (I mean, not many persons are working on gnustep itself
!), I don't really know how much persons will work in the end on this
hypothetical new desktop.
In fact... I'm starting more and more to think that GNUstep, instead
of trying to be a jack of all trades -- I mean, it's a programming
toolkit, no, a development environment with RAD, no, a web application
server, no, a desktop with a filemanager... etc. -- should "split"
into its sub projects ("technically" not, perhaps, but "publically"
yes).
Letting each sub-project stands on its own would enormously improve
the outside readability of the whole, and, I think, help attracting
new people more easily. It's perhaps a simple as (yet again) working
on the website to put everything into a "GNUstep" umbrella, but having
different, clearly separated sections...
Beside, coming back on the desktop idea, what exactly is wrong with,
ah, say, étoilé ;-) ? (it's not like we are not happily welcoming new
members or not doing any progresses)
--
Nicolas Roard
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Re: Objective-C 2.0
On 8/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The APSL is a Free Software License [1] according to the FSF. It is incompatible with the GNU GPL, but it is Free Software. It can be distributed and used by anyone, anywhere. Being Free Software, it can be included in Debian, Ubuntu, Fedora, SUSE, and anything else you can thing of. The only reason that the GNU objc runtime still exists is because the few people involved either don't like it for personal reasons (I worked hard on this!) or political reasons (Its maintained by a company that [*gasp*] sells software!). As far as I know, the reasons are mostly historicals -- NeXT didn't release their runtime, hence the need for GNU to rewrite one. Since then, there's also some partical differences (api differences, some parts of the GNU runtime are a bit faster than the NeXT one, and vice-versa). I'm unsure about the current licensing of the apple runtime, although if it's APSL it's a problem -- if it's APSL2 it's better (but even so, I think debian has problems with that licence -- see Squeak...). Anyway the problem for people outside the apple platform is that 1) indeed it will likely take time to implement the new features in the GNU runtime 2) existing software can have problems running with the apple runtime (I know that GNUstep didn't last time I tried, although I think it probably would not be that much work to make it work again, but well..). In my opinion it's a shame to have both runtime, as in a way it's a stupid duplication of efforts; but on the other hand APSL2 is not good enough even if it's a free software license, considering that GNU think it's incompatible with the GPL. Apple could release it under the BSD licence, or dual-licence it; but somehow I have some doubts they'll do that. Anybody with more insight about those problems please come forward -- I'd love more informations/positions.. Specifically -- what would be the needed steps for having only one runtime, acceptable for all the parties -- note that it would also be of interest (imho) for Apple to have ObjC be considered a more portable/not tied to one platform language... -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Nib compatibility progress
On 5/12/06, Adrian Robert <[EMAIL PROTECTED]> wrote: This is indeed looking pretty good -- aside from some layout spacing issues mainly on the right, almost perfect in fact. Are connections working as well? Likely this layout spacing is caused by the fact that Cocoa widgets have a "border" -- to have the shadow, etc., while GNUstep widgets do not. I guess the solution would be to either recompute the layout to accomodate that difference, or to change the way GNUstep widgets are drawn so they too use a border. The second option is more work, and will impact existing GNUstep applications too. Although including this border will also be helpful for our own GNUstep themes, and we don't have that much applications that redoing the ui (particularly with Gorm) would be too long... Also, just out of curiosity, what is that terminal application running in the background on the GNUstep shot? It looks like a GNUstep app, but as far as I recall Terminal.app was not able to display a white background? Looks to me like an xterm compiled with nextaw, the xaw implementation that looks like the NeXT ui.. -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: google summer of code
On 4/17/06, Nicolas Roard <[EMAIL PROTECTED]> wrote: > On 4/17/06, Adam Fedor <[EMAIL PROTECTED]> wrote: > > I'd think it's a nice idea. Is anyone willing to be a mentor, or at > > least put together a list of potential projects? > > I started a wiki page: > http://mediawiki.gnustep.org/index.php/Summer_Of_Code_2006 If we want to participate (I wouldn't mind participating as a student for instance, and I know others are interested too), we should send google a mail soon I think.. (considering the growing list of organizations..) -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: google summer of code
On 4/17/06, Adam Fedor <[EMAIL PROTECTED]> wrote: > On 2006-04-15 04:39:23 -0600 Nicolas Roard <[EMAIL PROTECTED]> > wrote: > > > Hi everybody, > > > > Google is running their "summer of code" program again this year: > > http://code.google.com/soc/ > > http://code.google.com/soc/mentorfaq.html > > > > It could be nice to submit GNUstep as a proposed organisation --- > > things like > > nib compatibility, cairo support, kvo, etc., could certainly be done > > over a summer > > by somebody dedicated... > > I'd think it's a nice idea. Is anyone willing to be a mentor, or at > least put together a list of potential projects? I started a wiki page: http://mediawiki.gnustep.org/index.php/Summer_Of_Code_2006 -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gui images
On 3/19/06, Ingolf Jandt <[EMAIL PROTECTED]> wrote: On 2006-03-19 19:34:51 +0100 Nicolas Roard <[EMAIL PROTECTED]>wrote:> I tried the images, the switch is ok, but the slider knobs aren't --> nothing > is drawn behind apparently, thus it display the slider background --> and theIt looks so much better with my colour scheme that I apparently didnot look close enough testing with the default one, I am sorry. (And I think one has to look close to see that this is not the wished lookfor the slider knobs).> tabs aren't good as well, as it seems the tab border's line is> displayed> behind the images.Gosh! Also this is practically invisible with my very bright theme. 2:0 for you.> I will commit the switch image and make a patch for the> two other widgets.Thank you and sorry for the inconvenience. This dark gray debris in mybright colour scheme was just so ugly. I committed the images and modified NSTabView, NSSliderCell to fill the background with NSColor controlBackgroundColor. Thanks for the images :-) -- Nicolas Roard"I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gui images
On 3/16/06, Ingolf Jandt <[EMAIL PROTECTED]> wrote: I was annoyed that slider knobs, swiches and tabs did not follow the color scheme, so I have edited their images.Unfortunately for the tabs the alpha channel was not rendered correctly (white with medium alpha appeared in a dirty gray on a very bright background), so I deleted the affected pixels and replaced my caringly designed ;-) smooth highlights with rough white lines. (Obviously this problem does not occur for the beautiful radio buttons, so it might be an issue with gimp.)Still I think that my tiffs are a big improvement over the present ones, so I would be glad if someone could commit them to -gui. I tried the images, the switch is ok, but the slider knobs aren't -- nothing is drawn behind apparently, thus it display the slider background -- and the tabs aren't good as well, as it seems the tab border's line is displayed behind the images. I will commit the switch image and make a patch for the two other widgets. thanks -- Nicolas Roard"I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: About gnustep-gui and camaleon
On 2/16/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: > Quentin, > > A number of the issues with Camaleon stem from the fact that it is not fully > integrated with gui. > > It might be time better spent to simply do the analysis to see what would be > necessary for integration and determine how to solve any issues via direct > integration. Yes, direct integration is the best way. Sorry to not have answered before, I didn't have a connection ;-) Anyway I have a few days off now before the fosdem, so I'll work on camaelon. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Planning Fosdem
On 2/12/06, Helge Hess <[EMAIL PROTECTED]> wrote: > On Feb 12, 2006, at 17:15, Nicolas Roard wrote: > > Well, yes, but the schedule is not uploaded on the fosdem site, so I > > would guess they don't have any schedule for us anyway... > > They know the reference to the Wiki site, I told them they'll find the > line-up over there ... Well, we'll see, if you want to know for sure, > ask the devroom list ;-) > > The FOSDEM site schedule is not used (internally), they asked for the > schedule in a separate mail. ah, ok then. > > Greets, >Helge > > PS: why did you cross-post? Er.. well simply because the original mail was crossposted.. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Planning Fosdem
On 2/12/06, Helge Hess <[EMAIL PROTECTED]> wrote: > On 12. Feb 2006, at 15:26 Uhr, Nicolas Roard wrote: > > I didn't hear any complaint about the planning, so well I guess it > > is fine ? :-) > > Note: AFAIK the FOSDEM flyers are already _in print_, so you can't > change the schedule as it was on the Wiki page anymore. Well, yes, but the schedule is not uploaded on the fosdem site, so I would guess they don't have any schedule for us anyway... -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Planning Fosdem
Hi, I didn't hear any complaint about the planning, so well I guess it is fine ? :-) Actually.. I had one remark saying we should start earlier the sunday because many people need to leave early... and I agree, it's a good point. So I modified the sunday planning to start at 10 am (9 am would be have been cruel) Windows Development with GNUstep -> 10:00 Richard Frith-Macdonald / Wim Oudshoorn Project Manager IDE -> 11:00 Sašo Kiselkov GroupDAV Meeting -> 13:00 Helge Hess OpenGroupware.org Project and Applications -> 14:00 Helge Hess Etoile Desktop Environment -> 15:00 Quentin Mathé / Nicolas Roard (it's on the wiki too: http://mediawiki.gnustep.org/index.php/FOSDEM_2006#Sunday) Comments ? -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
FOSDEM 2006 preparation
Hi, The next Fosdem is coming soon (25&26 feb !) in Bruxelles, and we should seriously finish the preparation of the GNUstep presence :-) -- sorry to send that mail only now, but I was really busy with RealLife... Talks Planning -- The current planning is available on http://mediawiki.gnustep.org/index.php/FOSDEM_2006 Note that it indicates 45 minutes talks, but we can either shorten or lenghten that.. I would like to ask everybody involved to check that this planning is fine for them, and to talk to me or helge if there's any modifications. If everything is ok I'll upload the final planning on the fosdem website monday. "Marketing" CD -- It would be nice to create a proper gnustep cd featuring the gnustep live cd, the fosdem presentations slides, documentation, etc. that we can distribute or burn at the gnustep booth. I would be *really* glad if somebody would to step in and accept to be in charge of the CD, but if there is no candidate I'll try to do what I can... It would be really nice too if the speakers could send me their presentation in advance, in order to include them on the CD :-) -- say, for the 20th. Video I will probably be able to bring a video camera with me but that needs to be confirmed. If somebody else can bring one tell me. Booth - We need brochures, booklets, posters, etc. Anybody want to be in charge of that part ? particularly to check the documents, possibly update them.. I still have some brochures from last year I think, I'll check that. What we need is color booklets though -- they were rather appreciated... One nice thing would be to have a GNUstep banner (simply a "GNUstep" text + the logo) -- anybody knows where we could do that and for how much ? To finish with the booth, I think it would be really good to have at least one "demonstration" PC showing a GNUstep environment. Anybody can bring a spare laptop or even a tower+screen ? (a laptop would be probably be better in fact, less annoying to carry ;-) Summary -- Fosdem is a very fun event with lots of interesting talks, and particularly for the GNUstep crowd it's our annual event where we can meet in real life :-) As we're a bit late into the organization, I would really appreciate any volunteer accepting to take care of a part of the organization -- particularly the marketing CD and the booklets/brochures printing job... Talk Persons: please check the planning !! Anybody else: please add yourself to the wiki if you're coming :-) Any other interesting ideas gladly welcomed ! ps: I wanted to organize a friday meeting/coding party (the fosdem beeing the saturday and sunday) to have the opportunity of getting rid of some bugs,etc, before the actual event... is anybody interested ? On the other hand, we could also organize some "coding party" during the fosdem itself too.. Cheers and have fun, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Camaelon crashing
On 12/2/05, oliver frommel <[EMAIL PROTECTED]> wrote: > Hello altogether, > > I am currently writing an article on Objective-C for the > German Linux-Magazin. In this connection naturally I come > to talk about GNUstep as well. As I am interested in > theme support I tried the Camaelon implementation out > of the Etoile-Snapshot available on the website. > > I get it to build (just the Camaelon bundle itself) and > install. However when I try to run a GNUstep app with > activated theme support (for instance GNUMail) the > application crashes with not very helpful messages. > With the GNUstep libs from gnustep-startup-0.13 I get > "recursion encountered handling uncaught exception". > > Is there anything I can do to fix this problem? > Is anyone still working on Camaelon? > How about the state of general theme support through it? Well, it should work, and I'm working on Camaelon. Which version did you use ? the one from Etoile's cvs, or the one from the svn ? We recently moved to svn, so the cvs version is deprecated.. Secondly, you need a recent version of the GNUstep gui libraries -- with the svn version of Camaelon, you possibly need the GNUstep cvs version actually. Lastly, did you install a theme ? And which one ? because at the moment only Nesedah is working (Nesedah.theme.tgz on http://www.roard.com/gnustep/), SimpleUI.theme.tgz is a bit outdated, while I use Nesedah to test things so it's sure to be up to date. Considering the general state of theming in GNUstep, well, it works through Camaelon, and I'm also working on integrating directly on gnustep the parts of Camaelon that modify AppKit widgets' drawing, so it will be even easier to create a theme engine (other than using Camaelon, say, if you want a theme engine for GNUstep/Windows that will use the Win32 theme api in order to have a proper integration.. or if you want a "programmed" theme) -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: DO compatibility with Apple DO
On 11/27/05, Jiva DeVoe <[EMAIL PROTECTED]> wrote: > Fair enough, sorry for asking a Q already answered there. > > I wonder if the change to OS X 86 + their XML format for archiving holds any > new hope for compatibility... does it? I suppose not. Well, if Cocoa uses XML for DO exchanges, I guess it could be possible in theory to have a compatible DO between GNUstep and OSX. But I really don't know if they use (or can be set up to use) XML instead of binary serialization for DO.. could be worth checking. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 10/26/05, Fabien VALLON <[EMAIL PROTECTED]> wrote:
> > By that I mean that if there are some obscure deprecated methods that
> > we don't have yet, I'm not sure it's worth implementing them/delay a
> > 1.0 just to claim "hey we're _fully_ OpenStep compliant !" -- it's not
> > like many people care about that (they care about OSX compatibility if
> > anything else).
>
> Of course,
> But it is not the case, and it will never be OSX ( current version )
> compatible.
Yes, but an important point is an easy for a developer to see what is
implemented is what isn't. We lack a bit of clarity here (that could
probably be resolved via the doc system).
> You will never release GNUstep if you follow Apple.
Of course, I didn't advocate to hold GNUstep until we're 100%
compatible with current Cocoa.. I was merely pointing that "OpenStep"
compliance is not really relevant today.
> Having a 2.0 release with Cocoa ("10.2 compliance") or windows will take
> longer.
>
> I believe at the "Release early release often".
I completely agree with you.
> > Same way, I don't think it's a good idea to orientate the 1.0 as
> > "Finally OpenStep-compliant", because as you say, the epidermic
> > reaction will be "yeah, good job guys, only 11 years to do it !".
>
> And ?
> who cares.
> It was hard work for the GNUstep developpers.
> Those guys are just stupid, don't listen to them.
Well, my wording was perhaps not right; what I meant is, you can't
boast a lot on OpenStep compliance when releasing a 1.0 when this
actually has very little importance for most of the people -- it's
counter-productive if you want to attract people. Of course, it is
important; just not a good "attraction" argument, and can even be
turned into a bad argument. I was just pointing that.
> >It would be more interesting to say something along the line of "we're
> > OpenStep compliant, we have our own additions, plus we are x%
> > compatible with Panther/Tiger ...", etc.
>
> That not exclusiv.
Of course. I don't care even about % of compatibility, but it's just
that we should have clearer presentation of what's actually
available/possible with GNUstep and the degree of compatibility with
OSX (imagine a cocoa dev going to gnustep.org for the first time and
trying to figure if its cocoa software can be ported to gnustep, and
what difficulties he can encounteer).
> Having ref. doc saying what should work and what should not would be great.
> But not a "Panther compliant" release ( not for 1.0 ).
yep.
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 10/26/05, Adam Fedor <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Fabien VALLON > > > > For the 1.0 release, what do you think about an > > "OpenStep-compliant release" ? > > > > - This is the first goal of GNUstep. > > - There is already some bugs to fix for "OpenStep-compliants" classes. > > - There is already documentation for "OpenStep-compliants" classes. > > Well, it's a bit boring. People will say, 'hey, you've caught up with 1999'. > Anyway, we're pretty much OpenStep > compliant except for some trivial methods. I agree; OpenStep-compliance shouldn't be anymore the definitive goal anyway.. By that I mean that if there are some obscure deprecated methods that we don't have yet, I'm not sure it's worth implementing them/delay a 1.0 just to claim "hey we're _fully_ OpenStep compliant !" -- it's not like many people care about that (they care about OSX compatibility if anything else). Same way, I don't think it's a good idea to orientate the 1.0 as "Finally OpenStep-compliant", because as you say, the epidermic reaction will be "yeah, good job guys, only 11 years to do it !". It would be more interesting to say something along the line of "we're OpenStep compliant, we have our own additions, plus we are x% compatible with Panther/Tiger ...", etc. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: why do we need change?
On 10/24/05, Dennis Leeuw <[EMAIL PROTECTED]> wrote:
> Actually I think Riccardo has some valid points.
> I would love to see Cameleon integrated into -core, but marketing wise I
> think releasing GNUstep 1.0, would do us more good then anything else.
Releasing GNUstep (gui) 1.0 would be good yes. But we need to identify
exactly what's missing and set precise goals for what a 1.0 should (or
not) provide..
Regarding Camaelon, it *does not* need to be integrated into -core at all !
Camaelon, as "a pixmap theme engine", is fine outside gnustep (even if
it could be committed on the gnustep cvs, possibly, but that's another
story). What needs to be done in -core is the whole part of Camaelon
that deals with integrating the pixmap engine ("Camaelon") with -gui.
Basically, properly separating the widgets rendering in
GSDrawFunctions instead of having it defined in each widget. So it's
more a refactoring than anything else..
Ok, I guess I should actually work on that and extract a proper patch
for -gui from the current Camaelon; as I said, it will amount to a
refactoring rather than adding new things, so for the
end-user/stability that shouldn't have any impact (hopefully ;-).
But once it's done, if you want to change -gui, you just need to
modify GSDrawFunctions methods; Camaelon will just provide an
implementation of GSDrawFunctions where the rendering in each methods
use pixmap rather than NSBezier et al. code..
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
On 10/22/05, Gregory John Casamento <[EMAIL PROTECTED]> wrote: GNUstep has been relatively stagnant over the last several months and it hasbecome a cause for concern for me. yes, many people seems to be quite busy irl lately :-/ I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows:1) More apps. Many of the following points will help with this, but this isvery important.2) Better theme support. Integration of Camaelon into the core gui library if possible that's possible, and I must say that's what I was supposed to do, more or less.. but I was really busy these last months, so I didn't do as much work on camaelon that I wanted :-/ Note that you can get the current sources from étoilé's cvs: http://www.etoile-project.org it wouldn't be that much work to properly integrate camaelon in -gui, but.. it needs to be done. I need to encapsulate the current -gui drawing in the GSDrawFunctions class, and integrate camaelon's modifs to -gui so that the widgets call GSDrawFunctions. Then Camaelon can simply provide its own implementation of GSDrawFunctions, enabling a pixmap theme, or you can have "programmed" themes containing normal code (for the default NeXTSTEP look, or anything else) Partly I didn't do it yet because I wanted to "freeze" the GSDrawFunctions api before starting to do that ... but well perhaps it would have been better to commit whatever was ready instead of waiting (retrospectively, it seems as a better idea). 3) Better win32 support. Many companies are really eager to port their legacyNeXTSTEP/OPENSTEP or Cocoa apps to GNUstep under Windows. The prospect of Linux and BSD support appeals to them as well, but not as much as Windows. I currently have two companies with whom I am talking about this. Completely agree ! A good Windows port is really important, and I'm quite thrilled by what happend during this last year.. 4) Better distro support. We really need to get GNUstep into as manydistributions as possile, this will ramp up exposure of GNUstep to more people and help us get more developers and users.We as a project need to be more adaptive and less resistant to change. Morethan anything right now we need to consider the audience we are playing to.GNUstep needs to be better able to integrate with other environments. Additionally, I've noticed recently a trend for certain people to constantlyquery the list asking for permission to make this or that change. It seemsthat what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) I completely agree :-) And I think that svn/svk could really help for that... hopefully we'll be able to use svn, now that RMS gave its approval... Please think about what I've said and let me know your thoughts. I say theabove out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. I think we're all here because we love the project; and we need to come up with a good direction.. I think what's missing is a clearer distinction between gnustep "the framework" and gnustep "the rest of the frameworks, the dev apps, the user apps".. I think having "separate" projects (GNUstep Development Environment, GNUstep Desktop), even if it only amount to just changes on the website, would be helpful. Also, GNUstep could be slightly modular (say, use -foundation but not DO..); and probably the "important" thing for the user would be a better separation/modularization of the desktop parts, eg, like Alex Malmberg once proposed with Desktop Bundles, where the desktop functionalities could be implemented/extended by desktop bundles (you'd want a "GNUstep" bundle to have the current behavior, but a "KDE" or "GNOME" bundle to have proper integration, etc.) Anyway, as always, talk is cheap, but I think thoses are the directions that would be helpful.. To summarize, cleaner separations and modularization... but anyway, what will happen only depends on who will do the job -- so if you're interested by working on that, do it :-) -- Nicolas Roard"Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep bounty
On 9/23/05, Adam Fedor <[EMAIL PROTECTED]> wrote: > On 2005-09-23 07:08:09 -0600 Adrian Robert <[EMAIL PROTECTED]> > wrote: > > > Speaking of financial incentives, what ever happened to the paid > > icons > > project that started up last year? Could someone from the UI list > > who might > > be listening update us developers on that status? > > I should forward the email from Quentin if I can find it, but > basically Jasper is still working on it, but since it has taken so > long, he has decided to do the rest of the icons for free. Basically, we gave 150$ (if i remember well) to Jasper in the beginning, as a first payment. He started to work, but then after some promising icons he stopped and was delayed for various reasons. Then he decided to make the rest of the icons for free, as he was so late. The current icons and some proposals can be seen here: http://www.jasperhauser.nl/projects/gnustep/ (jasper even wrote a complementary guideline for creating icons.. note that he misunderstood and he uses étoilé where he should have used gnustep ;-) (the icon guidelines we wrote with quentin were for gnustep, not étoilé, even if étoilé uses them). -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo backend
On 8/28/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Some of you may have noticed that this week the release 1.0 of cairo has > been published. For quite some time GNUstep has had a backend based on > this graphics library. But this has always been incomplete and also > cairo has changed a lot over the months. In the last few weeks I cleaned > up the code for this backend and extended it a bit. Basically it is now > ready to try it, although many features are still missing. Wow, excellent news ! > Known limitations: > - fonts are still hard coded > - text in NSTextView sometimes doesn't get displayed > - images are often displayed incorrect > - copying from one GState to another uses wrong transformation > - some minor operations are missing or untested > > I hope to solve these problems within the next month and will make a > public announcment for the cairo backend after that. If you find other > bugs, feel free to report them, or even better help to resolve them. I'll try to install cairo and test that :-) thanks, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Sorry, some things seem to have gotten mixed here. I wrote that "in the > end" this will "allow pattern images". They are not already there after > the first patch. Support for pattern colours requires two steps in the > backend: It needs to know, which image pattern to use, which is what I > implemented (the result of a pattern colour set command). And it needs > to draw this image, when a fill operation happens. I did not even work > on this second bit. Ah ok, my mistake. > Now art has an implementation of the very powerfull shfill PS command. > This allows, amongst other things, a pattern fill. So here the second > bit is already persent, while the first bit was missing. It should be > rather simple to implement full pattern colours drawing for the art > backend now. But this is nothing I am planning to do. The whole > structure of the art backend is very foreign to me. I don't dare to > touch anything here, because I may easily break things in an environment > that is so contrary to the way I normally program. > What I was planning to do was add a simple (and of course slow) pattern > drawing mechanism for the gsc classes and perhaps overwrite this with a > faster one for the xlib backend. > > Perhaps you could add the art pattern fill bit and I provide the rest? Well, I don't know about the art backend internals either -- It probably would be quicker if alex does it :-P -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Adrian Robert wrote: > > > > On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: > > > >> I just added changes to GUI and back that will in the end allow pattern > >> images for GNUstep and the new MacOSX composite operator that uses an > >> addtional alpha value. I wanted these changes to go into the next > >> release as this will break binary compatibility between GUI and back. I > >> have tested this change with xlib. It would be great, if somebody could > >> test it before the release with art and winlib. > > > > Is there an easy way to test it? Is there something in the new test > > suite that exercises this facility? > > > > > Here is the simple application I tested with. But I am not even sure if > the different operators have been implemented correctly for xlib, but > thenm only one of the images I use has alpha values. Perhaps I should > test with to transparent images. This test is only for composition, but what about the pattern images ? The "filling patterns" you are talking about, is setting an image to a color and then fill something with this color, right ? I'm asking because when I profiled Camaelon, pattern filling was one of the thing that took lots of time, and i'm hoping that by having the possibility to use filling pattern directly it will be faster (as you shouldn't need context switching during the filling). And, does it properly follow the current path mask ? (actually I think that doesn't work on xlib, only with art, anyway...) Thanks, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Looking like Windows on Windows
On 7/11/05, Jonathan 'Wolf' Rentzsch <[EMAIL PROTECTED]> wrote: > Hi all, > > What can I do to make my GNUstep/Windows app look like a 'native' windows > app? > > I know there's still work to me done making the menubar act like Windows' > per-window menubar, so I'm not asking about that. > > Instead, I'd like my app to look less foreign. Using the system-supplied > colors and at least paint widgets that look like WinXP widgets. > > I know WindowMaker is themeable, but I haven't seen a WinXP-style theme > for it. In fact, WindowMaker themes seem limited to just replacing widget > backgrounds and fonts. Keep in mind that WindowMaker has NO relations with GNUstep, other than beeing the prefferred window manager under X11. WindowMaker doesn't use GNUstep, is programmed in C, etc. It uses its own toolkit, so any toolkit comparisons between GNUstep and wmaker are meaningless... The "plan" (at least mine) to have GNUstep apps looking like windows apps is to create a Camaelon theme, and possibly another gui bundle so that GNUstep system colors would be read from the windows system colorlist. Note that you could also change the system colorlist on gnustep already, either by hand (add them in your defaults), by code, or by using the Preferences.app colorpref module. With the right colors (http://www.roard.com/screenshots/gnustep-windows.png) gnustep apps looks more integrated (I believe the gdi backend has now resolved the "black" parts in transparent images, right?). Note the winzip window in the lower right of the sshot. Of course, a real "windows theme" would be ideal. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
ANN: StepTalk Palette 1.2
Hi, I uploaded STPalette 1.2 on http://www.roard.com/gnustep/ STPalette-1.2.tgz Changes: addition of StepTalkClass in the lib and the palette :-) if you want to redo the demonstration on http://www.xdev.org/gnustep/ demo.html , you can reuse the Calculator.gorm included in the CalculatorExample directory. The file calculator.st contains the sourcecode. more infos on http://camaelon.blogspot.com Cheers, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Le 15 juin 05 à 23:38, Adam Fedor a écrit : Alex Perez has suggested using some of the funds that GNUstep has (and/or directed donations from individuals) to fund a part-time programmer to improve GNUstep. Some specific projects include CoreData and Predicates. Are other people interested in seeing these things added to GNUstep? I think it's a good idea -- some of the recent additions by Apple like the bindings, CoreData, CoreImage.. are really interesting, so if we can manage to implement them it will be a good thing to the project -- First, it would help developers porting their apps on gnustep and vice-versa; but moreover, thoses kits are really cool by themselves :) -- particularly the bindings and CoreData. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
ANN: StepTalk Palette 1.1
I worked a bit on the steptalk palette today, and I added some nice improvements... obligatory screenshot: http://www.roard.com/screenshots/ screenshot_steptalk_palette2.png You can create script outlets on the fly -- no need to use the object1,object2,...object9 limitation.. :-) I added a non-ui object that you can instanciate as any object The StepTalkView is still there, but more like a button containing a script. And actually by default its target/action is itself, so when you click on it, you execute the script. To change the default image, just dragn'drop another on it :-) added a connection inspector to only show the script outlets So basically now, it's more useable :-) and starts to be quite nice. Check the readme files for more infos. You can download it from here: http://www.roard.com/gnustep/STPalette-1.1.tgz enjoy :) -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: StepTalk Palette 1.0
Le 15 juin 05 à 08:21, Stefan Urbanek a écrit : Citát Nicolas Roard <[EMAIL PROTECTED]>: Well, it's easy to make a non-appkit object, but as I'd still want a view anyway, .. hmm.. I need to try, perhaps just defining the view in the palette will be enough after all, you're right. Is not what you want a kind of a diagram editor instead of a panel + view? Both can be useful I think... a view is nice if you just want to drop a script near the widgets ;-) -- Nicolas Roard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: StepTalk Palette 1.0
Le 15 juin 05 à 07:38, Stefan Urbanek a écrit : Citát Gregory John Casamento <[EMAIL PROTECTED]>: I only have one comment. The object doens't have to be a view. It can be any object at all. So it's possible to just use a normal step talk object instead of making StepTalkView. :) I know, I know :-) I was going to create a non-view object as well, but in fact having a view is quite nice after playing with it -- you could even create a panel (hidden by default) just to group them as you want... I also have other ideas, we'll see. Well anyway I'll add a non-view object too for the next version, it's not exactly hard to do and it could be useful too :-) We can discuss this later. I add that if you can make non-appkit object that would be included in an application, then I can add it to the StepTalk.framework. Therefore there would be no need for other library to link. The Gorm part is, of course, up to Greg. Well, it's easy to make a non-appkit object, but as I'd still want a view anyway, .. hmm.. I need to try, perhaps just defining the view in the palette will be enough after all, you're right. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
ANN: StepTalk Palette 1.0
Hi, I wrote a Gorm palette that let you create StepTalk scripts you can drag'n drop on a window, and connect objects to it. For example, it can easily be used to create the famous "calculator" example (3 textfields plus a button..). It works well, and I figured some people here could be interested (plus it's an example of how to make a palette). It's here: http://www.roard.com/gnustep/STPalette-1.0.tgz licenced under LGPL. More informations about the why and how here: http:// camaelon.blogspot.com , and check the READMEs. You need to install first libStepTalkView then compile the palette itself and load it in gorm. If you want to use this view in your app you need to link your app to libStepTalkView. Have fun ! -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: General GNUStep future develoment question
Le 15 avr. 05, à 21:35, cm a écrit : Hello I apologize for not having posted correctly, I didn't remenber the adress of the list and did a reply to a non related post. Sorry again, and thanks for the answer. I just thought that with Etoilé being a complete DE or even a complete system more source compatibility with Apple was a possible goal and I interogated myself to know if it was legally possible. Well, Étoilé's goal never was to *clone* the Apple dektop or Apple API ! Concerning the API implementation, I don't see why legally (apart from software patents problems) it should be a problem, as long as you use the public headers for creating your implementation, and don't base your code on Apple's. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Drawing optimization question
Le 9 mars 05, à 17:15, Adrian Robert a écrit : Hi, I'm drawing directly to a view, either using [NSString -drawAtPoint..] or, say, with NSRectFill() and friends. In addition to what you describe (flush problem?), NSString -drawAtPoint: has apparently a huge resource load, as each time you instanciate a layout manager, etc. Plus the cache size in NSStringDrawing is imho too small (we did some profiling with quentin during the fosdem using Shark, on a tableview containing lots of lines/columns, and with the current values, we had a 50% hit miss with NUM_CACHE_ENTRIES=16). I'm not sure why we care about the layout manager for NSStringDrawing -- it seems to me that you don't really want/need to bother with one in general if you're using thoses methods.. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
