Re: [Gimp-developer] Plugin compilation problems on 64 bit system
Hi, On Thu, 2007-05-24 at 23:33 +1000, David Hodson wrote: I've just received an email from someone who's getting link errors while trying to compile my DBP plugin on the following setup: system Fedora FC6 2.6.20-1.2944.fc6 x86_64 GNU/Linux running gimp 2.2.14 gimp devel is installed Most probably a confusion with the development version. Is he/she trying to compile against gimp-2.2 or gimp-2.3? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top‑5 GIMP user re quests...
Hi, On Fri, 2007-05-25 at 02:15 +0200, peter sikking wrote: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html BTW, the dialogs that you consider to be unnecessary can already be skipped using the Shift key. Sure, perhaps not the most intuitive and discoverable approach, but it works well for our power users. And sometimes the dialogs are not that unnecessary at all. So we can't just remove them. At least not all of them. Some UI streamlining is definitely needed, but the solutions aren't necessarily as simple as you put them. Actually a lot of what you say in your blog entry is well-known and there are bug reports for it already: http://bugzilla.gnome.org/show_bug.cgi?id=85579 http://bugzilla.gnome.org/show_bug.cgi?id=109929 http://bugzilla.gnome.org/show_bug.cgi?id=121087 These things are on our TODO for quite a while now. The problem is that they are very difficult to implement. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin compilation problems on 64 bit system
Sven Neumann wrote: Most probably a confusion with the development version. Is he/she trying to compile against gimp-2.2 or gimp-2.3? Should be all gimp-2.2, AFAIK. I'll ask him to check that everything matches. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
On Fri, May 25, 2007 at 02:15:32AM +0200, peter sikking wrote: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html On 4. better painting tools: So you propose to have brush models in tools like dodge/burn. Why would this be preferable to having modes like dodge/burn inside brush tools? Maybe brush model and mode should be handled separately? A: The region/scope to work on - whole image - a layer/group/set - a selection - brush strokes as they happen B: Options for above - mainly brush model with parameters comes to mind C: The action or drawing mode to apply - transformations - filters - paint On power modes Sounds like a rather vague distinction, makes me wonder if is such a good idea to split the modes based on it. Shouldn't layer and paint modes be kept the same? dipping and smearing Considering GIMP is not and shall not be painter ... but this would be very nice especially for drawing from scratch ;) On versions and approaches I have been using layers for versioning, backup, too. It just works. Of course real, branched versioning would rock. How much I would like to see it everywhere. Maybe there's a chance of pushing part of the functionality out, so it can become part the environment and have a wider developer pool? Regarding adjustment layers and GEGL GEGL is graph based, somewhat comparable to the nodes in Blender, right? If so, the concept of a layer stack does not match GEGL. I would propose to go all nodes and have no layers, if the layer stack wouldn't match the common case so nicely. On window management I have been thinking: What if GIMP was represented by a window with just the main menu. Image windows could be dockable palettes. Requires docking side-by-side. For SDI style, one would dock one image window and the inspectors all to the main window. Several images could docked together to have tabs. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
On Fri, May 25, 2007 at 05:25:14PM +0200, [EMAIL PROTECTED] wrote: If everything ends up dockable and there is no longer the freedom to place windows where you _need_ then to be I think it should stay as it is. Maybe that was the fundemental reason for this rather unusual set up in the first place. I talked about dockable, not forcing things to be docked. The only necessary restriction of placement of floating palette windows would be palette headers right above docking areas (as that should trigger docking). I'm confident this could be arranged to be no issue in actual use. Actually, if you think about it, docking would happen when you move a palette close to the bottom or side of another palette, so the then docked pallette ends up pretty much where you move it to, but tightly arranged, most space efficient. Or if you moved it on top of another palette, you get a tab and can easily switch to what would be completely obscured otherwise. I know this sort of thing is possible in win32 API but I dont seem to be able to find any linux progs, gtk+ or qt derived, that have freely floating windows or panels. So what if GIMP became the first? -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Webdesign is wrong
What gimp is not: not a web page mock-up application I brought up web mock-ups, but we realised that seriously supporting this would mean introducing a ton of functionality; it is better done in a specialised application I really don't understand what tons of functionality you mean. The most bothering shortcoming for webdesign workflow is slice tool and save for web (integrated into one app). Maybe your research methods are wrong. Webdesigners DO NOT design elements of page separately. Webdesigners DO NOT slice page and then open sliced files to save them for web. It would be great waste of time. As a matter of fact approach 'not a web page mock-up application' means that gimp is useless for any modern form of webdesign. PS I didn't intend to offend anyone. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Problems with GIMP from latest SVN
Hello, I built GIMP from latest SVN on Ubuntu 7.04 i386. It works almost OK, but when I try to create a new layer with layer fill type set to Transparency, it crashes with this output in the console: *** glibc detected *** gimp: double free or corruption (!prev): 0x0a2bb568 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb74d87cd] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb74dbe30] /usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb75fe131] /usr/lib/libgobject-2.0.so.0[0xb772cfa1] /usr/lib/libglib-2.0.so.0(g_datalist_id_set_data_full+0x347)[0xb75e4b87] /usr/lib/libgobject-2.0.so.0[0xb772d689] /usr/lib/libgtk-x11-2.0.so.0[0xb7bc2e31] /usr/lib/libgtk-x11-2.0.so.0[0xb7cbe4a1] /usr/lib/libgtk-x11-2.0.so.0[0xb7cca826] /usr/local/lib/libgimpwidgets-2.0.so.0[0xb7e2d60c] /usr/lib/libgobject-2.0.so.0(g_object_run_dispose+0x50)[0xb772dcc0] /usr/lib/libgtk-x11-2.0.so.0(gtk_object_destroy+0x7e)[0xb7bc2b2e] /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_destroy+0x45)[0xb7cbe755] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__INT +0x59)[0xb7738729] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b] /usr/lib/libgobject-2.0.so.0[0xb773c103] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb773d627] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9] /usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_response+0x5a)[0xb7b1e13a] /usr/lib/libgtk-x11-2.0.so.0[0xb7b1e195] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID +0x49)[0xb77389d9] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b] /usr/lib/libgobject-2.0.so.0[0xb773c103] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb773d627] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x53)[0xb7ad2163] /usr/lib/libgtk-x11-2.0.so.0[0xb7ad3bd5] /usr/lib/libgtk-x11-2.0.so.0[0xb7ad3c9c] /usr/lib/libgtk-x11-2.0.so.0(_gtk_marshal_BOOLEAN__BOXED +0x60)[0xb7ba26b0] /usr/lib/libgobject-2.0.so.0[0xb7729e49] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b] /usr/lib/libgobject-2.0.so.0[0xb773c753] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0xb773d3ef] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9] /usr/lib/libgtk-x11-2.0.so.0[0xb7cb6e18] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x19a)[0xb7b9b9da] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x317)[0xb7b9cbc7] /usr/lib/libgdk-x11-2.0.so.0[0xb7a1e12a] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0xb75f6df2] /usr/lib/libglib-2.0.so.0[0xb75f9dcf] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb75fa179] gimp[0x80671e9] gimp[0x80681a3] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7486ebc] gimp[0x8066ee1] === Memory map: 08048000-083b7000 r-xp 08:01 212414 /usr/local/bin/gimp-2.3 083b7000-083cb000 rw-p 0036e000 08:01 212414 /usr/local/bin/gimp-2.3 083cb000-0a6e2000 rw-p 083cb000 00:00 0 [heap] afe75000-afe8 r-xp 08:01 2234 /lib/libgcc_s.so.1 afe8-afe81000 rw-p a000 08:01 2234 /lib/libgcc_s.so.1 afe92000-b0743000 rw-p afe92000 00:00 0 b0743000-b074a000 rw-p b51dc000 00:00 0 b074a000-b0751000 rw-p b074a000 00:00 0 b0751000-b078c000 rw-p b0751000 00:00 0 b078c000-b0792000 rw-p b078e000 00:00 0 b0792000-b0a43000 rw-p b0792000 00:00 0 b0a43000-b0a44000 r-xp 08:01 9924 /usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so b0a44000-b0a45000 rw-p 08:01 9924 /usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so b0a45000-b0ce1000 r--p 08:01 211330 /usr/share/icons/hicolor/icon-theme.cache b0ce1000-b1388000 r--p 08:01 58233 /usr/share/icons/gnome/icon-theme.cache b1388000-b15ad000 rw-p b1388000 00:00 0 b15ae000-b16cc000 rw-p b15ae000 00:00 0 b16cc000-b16f6000 r-xp 08:01 7734 /usr/lib/liblcms.so.1.0.15 b16f6000-b16f7000 rw-p 00029000 08:01 7734 /usr/lib/liblcms.so.1.0.15 b16f7000-b1e2a000 rw-p b16f7000 00:00 0 b1e2b000-b1e34000 rw-p b1e2b000 00:00 0 b1e34000-b1e36000 r-xp 08:01 212422 /usr/local/lib/gimp/2.0/modules/libcolorsel_water.so b1e36000-b1e37000 rw-p 2000 08:01 212422 /usr/local/lib/gimp/2.0/modules/libcolorsel_water.so b1e37000-b1e39000 r-xp 08:01 212419 /usr/local/lib/gimp/2.0/modules/libcolorsel_cmyk.so b1e39000-b1e3a000 rw-p 2000 08:01 212419 /usgimp: terminated: Cancelado [EMAIL PROTECTED]:~/gimp$ (script-fu:23889): LibGimpBase-WARNING **: script-fu: wire_read(): error I have originally built GIMP with -O3 for CFLAGS, so I tried rebuilding it again without any specific CFLAGS setting, but still no luck. How cna I fix that? Thanks. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Fist of all, I want to thank Peter for his excellent work. I'm glad to see that several problems of GIMP's GUI are being revisited and most of the solutions suggested will be welcome in future releases. I don't agree with #1 request, though. I know that this has been a frequent request for years, but I think it's just a matter of habit. I'm a Photoshop user, and a Gimp user, too. After a couple of days I could understand the power of floating windows. Switching between floating windows and fullscreen with F11 is fast and easy, and my workflow is far better this way. And when I connected a second monitor it was even better. Floating windows ROCK! Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all. I think it would be better to improve the way those floating windows work: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) - by making toolbox and dockers dependant of the canvas window. As it was discussed before, this brings a new problem: where should the menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window when we open the program. Maybe the best option is to create a new kind of splashscreen, where we get as options: -Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the document/s window/s. (I'm thinking about something like the latest Adobe Premiere Pro initial screen, for instance, but in the GTK/floating windows fashion) Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here: http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg Well, just my two cents. Thanks again for your work! Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
