Re: Creating PDF reports
El mar, 26-02-2013 a las 22:04 -0500, Steven LeMaire escribió: > Hello Everyone, > > I'm looking at writing a simple program that will run scheduled on a server, > which will query a database and using the results, generate a PDF report to > be emailed to some users. I'm not too sure how I should go about doing this, > my first attempt at this was to write a tool that creates an NSTextView, and > simply inserts the text into it. It would then use the NSPrintOperation > PDFOperationWithTextView method to create an NSMutableData object, which > could them be written to a file. > > The problem I'm having now is, it requires AppKit, so I'm building with > application.make included in my makefile, but it then is complaining there's > no shared application object. > Basically, I don't want a graphical interface, so I'm not sure where to go > from here. > > Any guidance would be appreciated. > > Thanks > Steven > Make a tool instead an app. You only need add in GNUmakefile: NEEDS_GUI = YES Regards. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Creating PDF reports
Hello Everyone, I'm looking at writing a simple program that will run scheduled on a server, which will query a database and using the results, generate a PDF report to be emailed to some users. I'm not too sure how I should go about doing this, my first attempt at this was to write a tool that creates an NSTextView, and simply inserts the text into it. It would then use the NSPrintOperation PDFOperationWithTextView method to create an NSMutableData object, which could them be written to a file. The problem I'm having now is, it requires AppKit, so I'm building with application.make included in my makefile, but it then is complaining there's no shared application object. Basically, I don't want a graphical interface, so I'm not sure where to go from here. Any guidance would be appreciated. Thanks Steven ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
On 26. 2. 2013., at 22:34, Lars Sonchocky-Helldorf wrote: > I doubt this would be possible since Linux (and so Android) uses a different > binary format. More likely is that you "develop once, deploy everywhere", > e.g. you just recompile your app for Android using GNUstep. So this is more a > help for developers than for pirates. Luboš is actually working on binary compatibility of OS X and Linux (and apparently iOS :P). Similar effort for iOS by Christina Brooks: http://crna.cc/magenta_source.html But, it'd definitely focus more on "develop once, deploy everywhere"; anything else is a bonus. :-) -- Ivan Vučica i...@vucica.net - http://ivan.vucica.net/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
Am 26.02.2013 um 21:20 schrieb Luboš Doležel: > On 02/26/2013 01:35 PM, Ivan Vučica wrote: >> But, I think offering a mobile GUI for use with a mobile window >> manager on a mobile device is not a bad idea either. Building a >> project that can equally well run under an existing environment (e.g. >> rendering into an Android GL ES context and routing Android events >> into UIEvents), be used for development on desktops (in Xephyr and >> Xnest or even directly) and be used for running on an new platform >> while at the same time offering a recognizable and >> as-compatible-as-possible API... well, I think that's a good thing, >> too. > > Well, should such think materialize, I'd be worthwhile - and relatively easy > in fact - to support direct launching of iOS apps on Android via Darling. > Although I imagine Apple wouldn't be too happy about this, since I assume > pirated iOS apps could then be run on (non-rooted) Android devices :-) I doubt this would be possible since Linux (and so Android) uses a different binary format. More likely is that you "develop once, deploy everywhere", e.g. you just recompile your app for Android using GNUstep. So this is more a help for developers than for pirates. cheers, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
On 02/26/2013 01:35 PM, Ivan Vučica wrote: But, I think offering a mobile GUI for use with a mobile window manager on a mobile device is not a bad idea either. Building a project that can equally well run under an existing environment (e.g. rendering into an Android GL ES context and routing Android events into UIEvents), be used for development on desktops (in Xephyr and Xnest or even directly) and be used for running on an new platform while at the same time offering a recognizable and as-compatible-as-possible API... well, I think that's a good thing, too. Well, should such think materialize, I'd be worthwhile - and relatively easy in fact - to support direct launching of iOS apps on Android via Darling. Although I imagine Apple wouldn't be too happy about this, since I assume pirated iOS apps could then be run on (non-rooted) Android devices :-) So far I haven't been lucky even with running a console iOS "Hello World" on Android, since the it segfaults even before Darling's main() is called. Crappy Android dynamic loader is to blame :-( I've had a lot of "fun" with it on other occasions, too. But I wish a lot of good luck to you. There is a *lot* of untapped potential in GNUstep... -- Luboš Doležel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
On 26. 2. 2013., at 12:52, David Chisnall wrote: > On 26 Feb 2013, at 08:21, Luboš Doležel wrote: > >> may I just ask what the intention behind implementing UIKit is? >> Having fun / better abstraction somewhere / iOS apps on Android? >> >> For the latter to be actually usable, we'd still need some sort of Android >> backend. I've seen Cairo working on Android, so it shouldn't be too >> difficult... > > AppPortable has a UIKit implementation that runs on Android, using native > Android widgets. An alternative would be to use the EGL back end for Cairo / > Opal and so have everything rendered via the NDK. I've laid out my thoughts previously back in 2011 [1], but here goes :-) While Chameleon, the existing implementation of UIKit-over-AppKit, is absolutely amazing and works very well, I still believe that something that uses Core Animation and theoretically can be expanded to support everything that existing UIKit implementation (Apple's) can support. AppPortable's offering is probably excellent for apps; maybe not so much for games or getting as close results as possible to Apple's. If I had to grab something to quickly port an app and get support along with it, I'd go with AppPortable or, for GL games, with Yeeco's StellaSDK, or with some other offering on the market. But, I think offering a mobile GUI for use with a mobile window manager on a mobile device is not a bad idea either. Building a project that can equally well run under an existing environment (e.g. rendering into an Android GL ES context and routing Android events into UIEvents), be used for development on desktops (in Xephyr and Xnest or even directly) and be used for running on an new platform while at the same time offering a recognizable and as-compatible-as-possible API... well, I think that's a good thing, too. Aside from that, I can't propose other projects that I think are very important for GNUstep, primarily because every time I look at the relevant sections of code, I get lost. One of those projects is allowing rendering into -[NSGraphicsContext graphicsPort] using Opal, and adding -[NSView setWantsLayer:] which would create an NSOpenGLContext (or a CGLContext) on the relevant view (e.g. that view's parent, to avoid issues with clipping). This would allow for use of QuartzCore/Core Animation mixed with GNUstep's AppKit, and hence allow more complex transformations and animations of the GUI element than currently possible. And -- adding backing with CALayers to NSView is (from what I understand) required for Chameleon. And since Chameleon exists, it makes little sense to replicate it just because of architectural limitations of GNUstep. Right? So reimplementing UIKit using AppKit doesn't sound interesting to me. I feel I'd need a lot, lot, LOT of guidance for integration of Opal and QC, and may not even succeed in a reasonable time frame. I may be wrong, though, and it may be way simpler if someone who understands internals of AppKit laid out a (detailed?) plan and wrote an explanation of the internals :-) Since I don't feel like I could do the required modifications, I propose the second best thing: starting to implement UIKit. If someone has a better and more interesting project, or can guide me in restructuring AppKit to integrate Opal and QuartzCore -- let's discuss it! [1]: http://lists.gnu.org/archive/html/discuss-gnustep/2011-09/msg00126.html On 26. 2. 2013., at 09:23, Maxthon Chan wrote: > p.s. Is there any tool that converts Xcode project into Makefile? Although this is completely unrelated, yes. Look into GNUstep's SVN repository, I think there is one tool that does just that (and another that builds directly from pbxproj). -- Ivan Vučica i...@vucica.net - http://ivan.vucica.net/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
On 26 Feb 2013, at 08:21, Luboš Doležel wrote: > may I just ask what the intention behind implementing UIKit is? > Having fun / better abstraction somewhere / iOS apps on Android? > > For the latter to be actually usable, we'd still need some sort of Android > backend. I've seen Cairo working on Android, so it shouldn't be too > difficult... AppPortable has a UIKit implementation that runs on Android, using native Android widgets. An alternative would be to use the EGL back end for Cairo / Opal and so have everything rendered via the NDK. David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Tooltips in save panels
Hi, Wolfgang Lux wrote: Fred Kiefer wrote: The backend implementation simply passes on the window level to the window manager if that is WindowMaker (which Riccardo is using), so I'm inclined to think that my comment _does_ reflect the implementation in XGServerWindow.m. Another point is that XGServerWindow also attempts to map window levels onto NET-WM window types for other window managers, which may or may not work well (for instance, the mapping is more or less broken when using Apple's quartz-wm). I am using Window Maker, yes. This could explain some things: tooltips work fine on Windows with win32! Also, sometimes tooltips are shown black in Gorm for exmaple (Gregory has this problem often). I never experienced this if not yesterday, but just clicking the windows made the problem disappear. I suppose there can be confusion in layering. I think Wolfgang's idea of putting them at popupbutton level is fine, it would solve most problems, except putting a label on a menu-item of a popupbutton itself (but it would when closed I suppose). Perhaps it should be done immediately post-release, but if you have a patch I can try it. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Tooltips in save panels
Fred Kiefer wrote: >> The problem is fairly obvious if you look at the source: Tool tips are drawn >> at NSStatusWindowLevel, which is well below NSModalPanelWindowLevel. I guess >> the tool tips would need to be drawn (at least) at NSPopUpMenuWindowLevel. >> Actually, I would think it should be even higher than that (allowing tool >> tips to be shown for pop up menu items) but there is no well defined window >> level above NSPopUpMenuWindowLevel (except for NSScreenSaverWindowLevel and >> that of course looks inappropriate). >> >> Wolfgang > > Your argument is correct, but it does not reflect the implementation we have > in XGServerWindow.m. But doing things the way you suggest in both places > would be better. The backend implementation simply passes on the window level to the window manager if that is WindowMaker (which Riccardo is using), so I'm inclined to think that my comment _does_ reflect the implementation in XGServerWindow.m. Another point is that XGServerWindow also attempts to map window levels onto NET-WM window types for other window managers, which may or may not work well (for instance, the mapping is more or less broken when using Apple's quartz-wm). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
About reimplementing UIKit, you can actually map UIKit to AppKit. Those code are largely similar. p.s. Is there any tool that converts Xcode project into Makefile? 在 2013-2-26，下午4:21，Luboš Doležel 写道： > On 25.2.2013 11:17, Ivan Vučica wrote: >> I think it might also be a better year for me to participate as >> well. >> >> I'd start preparing this week by working on: - an OpenGL and OpenGL >> ES wrapper that would be usable by not just AppKit apps (a thin >> wrapper around GLX that uses CGL API) - by moving QuartzCore to use >> that instead of AppKit >> >> If I have some results by the deadline for student registration, I >> would feel confident to register this year, so it gets to be an even >> better experience for everyone :-) >> >> The project would be: an implementation of parts of UIKit, along with >> patching QuartzCore where needed. >> >> Thoughts? >> > > Hi, > > may I just ask what the intention behind implementing UIKit is? > Having fun / better abstraction somewhere / iOS apps on Android? > > For the latter to be actually usable, we'd still need some sort of Android > backend. I've seen Cairo working on Android, so it shouldn't be too > difficult... > > -- > Luboš Doležel > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GSoC Mentors Announce] Google Summer of Code 2013
On 25.2.2013 11:17, Ivan Vučica wrote: I think it might also be a better year for me to participate as well. I'd start preparing this week by working on: - an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit apps (a thin wrapper around GLX that uses CGL API) - by moving QuartzCore to use that instead of AppKit If I have some results by the deadline for student registration, I would feel confident to register this year, so it gets to be an even better experience for everyone :-) The project would be: an implementation of parts of UIKit, along with patching QuartzCore where needed. Thoughts? Hi, may I just ask what the intention behind implementing UIKit is? Having fun / better abstraction somewhere / iOS apps on Android? For the latter to be actually usable, we'd still need some sort of Android backend. I've seen Cairo working on Android, so it shouldn't be too difficult... -- Luboš Doležel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
