discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a window for a tool


From: Pascal Bourguignon
Subject: Re: a window for a tool
Date: Tue, 21 May 2002 20:45:39 +0200 (CEST)

> From: Chris B.Vetter <chrisv@web4inc.com>
> Date: Tue, 21 May 2002 10:22:44 -0700
> 
> On Tue, 21 May 2002 16:48:18 +0200 (CEST)
> Pascal Bourguignon <pjb@informatimago.com> wrote:
> > > From: Enrico Sersale <enrico@www.imago.ro>
> > > Date: Tue, 21 May 2002 13:36:51 +0300 (EEST)
> > > I remember that this was already discussed some time ago on this list,
> > > but I've lost the mail :-)
> > > Can I have a tool showing a modal window when it needs some information
> > > from the user? Is an example somewere?
> 
> I've asked that a few months ago (as well?), but got no answer.
> 
> > Have a look at my filesel tool (you can get it from:
> >      http://www.informatimago.com/develop/gnustep/index
> > It shows the  NSOpenPanel or the NSSavePanel.  You  can similarly show
> > any modal  window. 
> 
> [... cat GNUmakefile ...]
> 
> include $(GNUSTEP_MAKEFILES)/application.make
> 
> [...]
> 
> It's not a Tool, it's an Application.
> 
> I just tried your idea on a 'real' Tool:
> 
>   GSFFCallInvocation.m:755  Assertion failed in GSInvocationCallback.
>   GSFFCallInvocation: Class 'FooBar' does not respond to
>   forwardInvocation: for 'methodForSelector:'
> 
> -- 
> Chris

What's a tool?  What's an application?

The  only difference  I see  when I  compile with  application.make or
tool.make is that with application.make, gnustep-gui gets linked.

Obviously, if you need to show up some panel in your tool, you'll need
a GUI.  (If  someone develops a front-end able  to display windows and
buttons on a text terminal, while  not strictly a *G*UI, it won't be a
mere  CLI,  and  would  still  be  called  a  "GUI"  and  linked  with
gnustep-gui).

So either you use application.make,  or you'll have to add gnustep-gui
to the libraries to be linked with your "tool".

Using for example, this (tested) GNUmakefile:
----------------------------------------------------------------------
GNUSTEP_MAKEFILES = $(GNUSTEP_SYSTEM_ROOT)/Makefiles

# Install into the system root by default
GNUSTEP_INSTALLATION_DIR = $(GNUSTEP_LOCAL_ROOT)


TOOL_NAME=filesel
filesel_OBJC_FILES=filesel.m
RCS_FILES = GNUmakefile Makefile.postamble
DIST_FILES = $(RCS_FILES) 
INSTALL_FILES = 

ADDITIONAL_TOOL_LIBS=-lgnustep-gui

-include GNUmakefile.preamble

include $(GNUSTEP_MAKEFILES)/common.make

OBJCFLAGS += -Wall -g

include $(GNUSTEP_MAKEFILES)/tool.make

install::
        install -m 755 filesel /usr/local/bin


-include GNUmakefile.postamble
----------------------------------------------------------------------



Now, obviously, a tool and  an application are not "packaged" the same
way.   An  application can  have  resources,  icons, localized  string
tables, etc.  A tool could be simplier, with just the executable.  But
I  would say  that as  soon as  you have  some GUI  elements,  you may
benefit  the resources  packaged  with an  application,  even if  it's
supposed to  be used  from the CLI  with arguments, stdin  and stdout.
That's  why I  choosed  to make  it  as an  application, installed  in
$GNUSTEP_LOCAL_ROOT/Applications/,  and  have  a  script to  exec  it,
forwarding the arguments, installed in /usr/local/bin/.



Libraries linked with a tool (for filesel.m):
    -lgnustep-base \
    -lobjc \
    -lz \
    -lcallback \
    -lavcall \
    -lxml2 \
    -lz \
    -lm \
    -lgmp \
    -lpthread \
    -ldl \
    -lm \
    
Libraries linked with an application (for filesel.m):
    -lgnustep-gui \
    -lgnustep-base \
    -lobjc \
    -lz \
    -lcallback \
    -lavcall \
    -lxml2 \
    -lz \
    -lm \
    -lgmp \
    -lpthread \
    -ldl \
    -lm \


-- 
__Pascal_Bourguignon__



reply via email to

[Prev in Thread] Current Thread [Next in Thread]