[Gimp-developer] STUB
Hi, I'm trying to compile and run the current cvs gimp. I know I have to expect to bug here or there, but I've seen quite a strange thing: When I run the gimp, it always segfault with this backtrace: #0 g_on_error_stack_trace (prg_name=0xbb78 "lt-gimp") at gerror.c:176 #1 0x4002a59c in g_on_error_query (prg_name=0xbb78 "lt-gimp") #2 0x808d57e in gimp_fatal_error (fmt=0x402d2dc0 "Segmentation fault") #3 0x80d9bac in gimp_sigfatal_handler (sig_num=11) at main.c:476 #4 #5 0x400fc0db in gtk_notebook_update_labels (notebook=0x8588f68) #6 0x400feabe in gtk_notebook_insert_page_menu (notebook=0x8588f68, #7 0x400fe8a5 in gtk_notebook_append_page (notebook=0x8588f68, child=0x0, #8 0x80d78b6 in lc_dialog_create (gimage=0x0) at lc_dialog.c:212 #9 0x807da7a in dialogs_lc_cmd_callback (widget=0xb970, #10 0x80f6a19 in session_open_dialog (info=0x8199038) at session.c:333 #11 0x4002dad5 in g_list_foreach (list=0x81f6134, #12 0x80f695e in session_restore () at session.c:305 #13 0x806a99c in app_init () at app_procs.c:675 #14 0x80699e0 in gimp_init (gimp_argc=0, gimp_argv=0xba68) #15 0x80d9b04 in init () at main.c:442 #16 0x80fcf72 in user_install_verify (user_install_callback=0x80d9af0 ) #17 0x80d9acb in main (argc=1, argv=0xba64) at main.c:408 The segfault is ovbiously caused by the call to gtk_notebook_append_page() (in frame 8) with NULL as a second parameter. After further investigation, it happens that this second parameter is the return value of the paths_dialog_create() function. Unfortunately, this function as been temporary replace by a "STUB" function (in tools/tool.c) which always return NULL. So the segfault is almost done on purpose. Is there a workaround so I can still launch the gimp and do further testing? Am I missing something obvious? Is there a way to compile the current gimp so one can at least see the toolbox and/or an edited picture? I know the current cvs gimp is not for a daily use. I just want to help. Thanks, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
On Sat, Feb 24, 2001 at 01:58:06AM +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote: > protocol for communication between plug-ins and Gimp that are all > running on the same machine, you are free to choose any non standard > protocol you like. It's free software. You are always free to use whatever you like. Nobody can force you to use some specific protocol for _network_ connections because it exists. > Other protocols like KDE's DCOP or MCOP as you mentioned are not serious > standards. Well, naming something "not a serious standard" is not a serious statement ;) (Why?) > Using shared memory is only useful when the two processes are running on > the same machine and you could still define a CORBA interface to set it > So if we want to open Gimp for a distributed environment This is true. But so far everybody who tried it seemed to have given up. Anyway, you call something "not a serious standard" which you obviously haven't even read. I was talking about MCOP, not shared memory. Yes, MCOP is extremely fast with shared memory. It also also quite fast with TCP (compare the average size of a corba packet with the mcop case for example. And I am talking reality here, not "but in theory CORBA could"). The only pre-existing argument in favour of CORBA is, in fact, that gnome uses it and to be very compatible with gnome you must base your software on corba. This argument might be a very important one (e.g. KDE doesn't use CORBA ;) since there are strong historical ties between gnome and gimp (the mother of it all). It does not mean that not thinking about alternatives is verboten. In fact, calling MCOP "not serious" without having looked at it just shows that most people do not even *think* about possible alternatives but just run blindly into some direction. Remember that I am not advocating MCOP here, but rather thinking critically about CORBA, it's usefulness and it's application. Just because CORBA was done by OMG *must* not mean to use it blindly. Otherwise we could just as well also follow windows instead of trying to innovate (the gimp menus, for one thing, are definitely non-standard. I would love them to become standard. But as they are, they are not a "serious standard" because neither a standards agency advocates them nor are they widely used). For example, what has CORBA done to gnome so far? All I see is a bewildering multitude of apis that most people don't understand. Gnome really *has* become a mega-API with functions for each and everything and then some. In practise this leads to hard-to-factor components because nobody understands the dependencies anymore. A famous example of this is the annoying stubbornness of many gnome applications to start a whole bunch of other processes (the gnome-panel for example), without being asked for. This leads to strange effects sometimes: On my neighbours display (often an IRIX machine) I can see the 4Dwm environment together with - for him - a quite useless gnome-panel and other gimmicks he cannot turn off except by closing everything (including his app). All that because he just started gnome-icu (or some other app). This has nothing to do with the beatifulness of a nice kernel/userspace abstraction with clearly defined interfaces (unix). (See for example Miguels article http://www.helixcode.com/~miguel/bongo-bong.html, which sounds like a lot of good arguments to make user/system communication more colourful and less efficient). What I am asking for is critical thinking (or at least active thinking). Not turning down something else because it isn't spelt C-O-R-B-A and no other reason. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Marc Lehmann wrote: > I'd like to remind people that corba is not the only way to go, as there > is also dco and especially MCOP (which was designed for realtime and > multimedia applications). While CORBA might indeed be the best choice, it > mustn't be choosen just because it has more letters ;-> > >http://space.twc.de/~stefan/kde/arts-mcop-doc/ > > (the author couldn't get corba to work reliably (timing constraints) so he > choose to implement something suited for data transfer). It depends largely on what you try to achieve. When you just need a protocol for communication between plug-ins and Gimp that are all running on the same machine, you are free to choose any non standard protocol you like. However, if you want to interface with other applications you must choose a protocol that is a real standard. Basically for the next few years there are only two real candidates in this area: CORBA and (I hate to admit it) Microsoft's DCOM/COM+. I have worked with both, and CORBA is a mature standard with some good implementations. Other protocols like KDE's DCOP or MCOP as you mentioned are not serious standards. Using shared memory is only useful when the two processes are running on the same machine and you could still define a CORBA interface to set it up. So if we want to open Gimp for a distributed environment I think CORBA is the right way to go. Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Marc Lehmann wrote: > I'd like to remind people that corba is not the only way to go, as there > is also dco and especially MCOP (which was designed for realtime and > multimedia applications). While CORBA might indeed be the best choice, it > mustn't be choosen just because it has more letters ;-> > >http://space.twc.de/~stefan/kde/arts-mcop-doc/ > > (the author couldn't get corba to work reliably (timing constraints) so he > choose to implement something suited for data transfer). It depends largely on what you try to achieve. When you just need a protocol for communication between plug-ins and Gimp that are all running on the same machine, you are free to choose any non standard protocol you like. However, if you want to interface with other applications you must choose a protocol that is a real standard. Basically for the next few years there are only two real candidates in this area: CORBA and (I hate to admit it) Microsoft's DCOM/COM+. I have worked with both, and CORBA is a mature standard with some good implementations. Other protocols like KDE's DCOP or MCOP as you mentioned are not serious standards. Using shared memory is only useful when the two processes are running on the same machine and you could still define a CORBA interface to set it up. So if we want to open Gimp for a distributed environment I think CORBA is the right way to go. Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
On Fri, Feb 23, 2001 at 04:53:14PM -0500, Michael Meeks <[EMAIL PROTECTED]> wrote: > I don't know what the gimp protocol is - clearly for _massive_ > chunks of data, shared memory is the only way to go. Vladimir has a nice > CORBA interface for dealing with setting up shmem chunks to do this I > think for his video editing toy. I'd like to remind people that corba is not the only way to go, as there is also dco and especially MCOP (which was designed for realtime and multimedia applications). While CORBA might indeed be the best choice, it mustn't be choosen just because it has more letters ;-> http://space.twc.de/~stefan/kde/arts-mcop-doc/ (the author couldn't get corba to work reliably (timing constraints) so he choose to implement something suited for data transfer). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Hi Nathan, On Wed, 21 Feb 2001, Nathan C Summers wrote: > Having plug-ins available to run on other hosts would be nice. Think > a gimp farm. CORBA would seem to be an ideal solution to all of these > issues. Can CORBA handle the large amounts of data transfer gimp > requires at least as efficiently as the gimp protocol does? I don't know what the gimp protocol is - clearly for _massive_ chunks of data, shared memory is the only way to go. Vladimir has a nice CORBA interface for dealing with setting up shmem chunks to do this I think for his video editing toy. The IIOP protocol is ( to my mind ) very efficient, I don't know how efficient the gimp protocol is but here are some details: * endianness aware - endianness is passed as a flag on the message to avoid redundant swapping * alignment is per type, char - 0 -> double - 8, binary encoding on the wire - ie. just dump the &variable ( aligned right ) to the wire. * strings, sequences have an associated 32bit length * sequence allows big chunks of data to be transfered with only a long length being associated. What else can I say - it's pretty efficient. No hint of slow -> xml type translation in the way. It is a nice protocol. HTH, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Fri, Feb 23, 2001 at 06:30:53PM +0100, [EMAIL PROTECTED] wrote: > Does this mean that you agree to ditching all the special code > for the 3 and 1 byte case as well? I'd really love to see this > changes although as already stated this might introduce a bit > memory overhead in case the user didn't use the alpha channel > at all. If we can get back COW during 1.3 this overhead is zero (all new channels / layers etc. can be created as COW tiles with the apppropriate contents -- huge speedup). I believe COW was lost because there were problems making it stable with all the spaghetti in 1.1.x, but presumably as we wipe out the worst of the spaghetti we should be able to bring it back, no? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 22 Feb, Sven Neumann wrote: > We'll face one problem if we decide to make alpha the default for all > images: A lot of fileformats do not understand alpha and you actually > don't want to save the alpha channel with the image at all if you > never touched it. One way to solve this would be to introduce a > function to check if the image's alpha channel is empty. This hint > could be set from the already existing tile-row hints without too > much overhead. As you said. For one we can use some special dirty flag for the Alpha channel and for the case of the non-alpha fileformats we simply do the same as now: Flatten image. Does this mean that you agree to ditching all the special code for the 3 and 1 byte case as well? I'd really love to see this changes although as already stated this might introduce a bit memory overhead in case the user didn't use the alpha channel at all. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] File location for plug-in auxiliary files
The installed version of a plug-in can contain other files than just the executable, e.g. help files and locale files. When the user has root permissions these files can be installed on the standard locations for the system, but where should these files be installed when that is not the case? The most logical place appears to be ~/.gimp-x.x/myplugin/. An alternative is to group help-files and locale info for all locally installed plug-ins together in ~/.gimp-x.x/help and ~/.gimp-x.x/locale. A related problem is how to find the local installation directory for the user, in ancient times this used to be ~/.gimp but this was changed (in 1.1?) to ~/.gimp-x.x. Gimptool does not return this directory even though it uses it for --install. So I would like to propose that a --gimpdir option be added to gimptool (It is a bit difficult a the moment because gimptool just mysteriously vanished from CVS). Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] introduction + localisation questions
On 22 Feb, Sven Neumann wrote: > The file README.i18n in the gimp tree provides more information > that might be interesting for you. Uhoh, that reminds me that it's really needed to rewrite that file... :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
