Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
[EMAIL PROTECTED] wrote: A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function. That would seem like a good idea for plugin. Could you point to some definative info on this use of CSS div containers? It would have to be a well defined structure in order to be able to formalise it as a plugin. /gg The correct way to design a webpage using XHTML+CSS is separating contents and presentation. Contents are divided in blocks (usually divs) and line elements that are styled in a separate stylesheet. The interfase wireframe is defined by those divs, following the W3C visual formatting model. My idea for that plugin consists in importing those divs (which have with, height and a relative or absolute position in the document structure, and background color), into solid color layers. Once the XHTML+CSS wireframe is designed, the design of graphic elements for incusion in the DIV (images, div backgrounds or dummy texts) would be very fast to achieve, letting the designer to create a mockup in a breeze. And that fast editable mockup would be ready for exporting the slices (I know, I said slices are a bad idea, but i mean slices as image blocks) for the final webpage. Slices as they are meant in Photoshop are bad because you tend to design the whole page using the incorrect application. A webpage isn't bitmap images sliced. Is hypertextual content with bitmap decorations. Photoshop makes unexperienced people think that anyone can design a website, when in reality that's not true. If we focus in the right way, we'll be focusing in creating the bitmap decorations for a specific html element instead of creating the whole mockup and automagically export it to a html page. It's ok to listen to users feature requests, but if Gimp is going to be a professional application, IMO the un-professional features shouldn't be included. ___ 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...
Thanks, I'm aware of the basic principals. But if something is to be formalised into a plugin there has to be some well defined way of working. Preferably a standard, not just a couple of jargon words like slices and wireframe. Oh, I'm sorry, I misunderstood you. I'm not a programmer. I was rather talking as a webdesigner and focusing on what would be really useful for webdesign. In this case, the image slicing process was mentioned as one of the top user requests, so I wanted to bring my point of view about it. Please let me know if this kind of oppinions are not appropriate for this mailing list. I know this list is for developers, but there are other topics discussed here, like program functionalities and interface related. Gez ___ 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...
Hi, On Sat, 2007-05-26 at 21:53 -0300, Guillermo Espertino wrote: That's much better, but if you set both toolbox and docker as utility windows, if you haven't any image open you don't have any window listed in the taskbar nor the task switcher (alt+tab). If it would work nicely, it would be the default setting. I think most users see the windows listed in the taskbar as applications running or minimized instead of windows. That's why I find this behaviour to be quite confusing. That's nothing that the application has to worry about. Most taskbars (even on Windows) can be configured to group windows of the same application into a single item. 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 requests...
On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote: 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) As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. 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 Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times) -- 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...
Thorsten wrote: On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote: Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all. As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. yep. 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 Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times) Thorsten has got a point with the preferred proximity of the tool options to the tool palette. As it looks and feels at the moment, these need to be close to each other to show their connection. One solution for this is to start tying the options to what actually gets done with the tool to the image, and start putting the options in heads-up displays near to where one is working. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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...
Peter said: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) I say no item in the window list. inspectors do not match users' goals, image windows do. I meant the items in the tray bar / lower panel of the O.S. desktop. The applications listing. Just one item Gimp instead of toolbox, image, docker as it appears now. My intuition tells me that such 'ms outlook' approach would work against the goal of GIMP being a high-end expert tool. I am much more enthusiastic about having the tip of the day in the main window in a 'no image' situation. And to have all new tips there, that can bring experienced users to the next level. To be honest, I had that idea when I was looking Ardour and Jokosher, then I realized hey, that's the same that the latest Adobe apps have!. It doesn't look to be working against Adobe Premiere Pro, Adobe After Effects and Adobe Encore (almost in the exact way I suggested) and Photoshop and Illustrator (in a similar way). So I'm not sure if it's incompatible with a high end, pro application. The tip of the day could be in that window too, and you'd have a great one-window solution for the whole problem. I think I should make a mockup. :-) We are investigating in the same direction at the moment, but I cannot decide for one million users that by default they can have either the tool options, or the color specifier. So I need to look for different compromises. Then Thorsten said this: As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. And this: Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. Good points. In the ideal world, Gimp would have MDI and floating as options, and presetable layouts by default. But we know that gimp hasn't enough developers, and this kind of features were never adopted because of that. I was myself one of the guys asking for optional MDI/Floating some time ago, and Sven replied that: every option in the preferences carry an important effort in coding as well as several changes in documentation. That's why I'm suggesting this layout chnge. It would gain much screen space without the need of much coding and documentation changes. I'm pretty sure that most of the user asking for MDI wouldn't have much problems with the layout I'm proposing. It's more photoshop-esque, and to be honest, users who ask for MDI so frequently are doing that because of Photoshop mostly (see the trend point in Peter's report). Most of the users got used to the default layout maybe because never knew that it could be changed. I'd like to know how they feel about getting a 15% more of work area. Maybe there should be a poll in the website, proposing a couple of tool layouts. Oh, and about semi-transparent toolbox and docker... it can be really tricky. IMO, Semi transparent windows in interfaces should be avoided because it's readability depends on the contrast between the foreground and background elements. Some combinations work great, some combinations simply don't. And when they don't, the new problem is worse than the problem that was intended to solve: a confusing mix with deficient contrast is worse than a slight obstruction. And why not to mention that semi-transparent windows are alien to the default GTK/gnome style guidelines. ___ 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...
Hi, On Sat, 2007-05-26 at 11:32 -0300, Guillermo Espertino wrote: I meant the items in the tray bar / lower panel of the O.S. desktop. The applications listing. Just one item Gimp instead of toolbox, image, docker as it appears now. I would actually want to have toplevel image windows listed in the task bar. But I don't see a point of having a GIMP item there. Palettes like the toolbox don't show up in the task bar anyway when they are set as utility windows. You can already configure GIMP to behave this way. 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 requests...
On Friday 25 May 2007 21:49, Guillermo Espertino wrote: 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 agree 100%. I had used Photoshop on a multimonitor setup for some time before moving to GIMP and had moved the tool windows onto the second monitor. So when I started using GIMP I liked the way this worked from the get go. One other thing that I also like is that each image is also in it's own window which I think is better the way Phototshop does this. Hal ___ 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...
Sven wrote: I would actually want to have toplevel image windows listed in the task bar. But I don't see a point of having a GIMP item there. Palettes like the toolbox don't show up in the task bar anyway when they are set as utility windows. You can already configure GIMP to behave this way. Oh, I didn't know that. That's much better, but if you set both toolbox and docker as utility windows, if you haven't any image open you don't have any window listed in the taskbar nor the task switcher (alt+tab). Default behaviour clutters the taskbar and the other setting makes the application almost invisible if you refreshed the desktop using the show destop applet. I think most users see the windows listed in the taskbar as applications running or minimized instead of windows. That's why I find this behaviour to be quite confusing. About the image slicing for webmasters subject... I'm against it. Save for web is a necessary tool because is a time saver and allows to see the balance between quality and filesize, which is a must-be for web design. But slicing is a horrible methodology created for home users. A real web designer designs a wireframe and the typographic structure before the graphic stage, then designs the elements needed, using the div placement and dimensions defined in the css layout. I mean: If you completed the wireframe stage and you defined the block elements with CSS, image slicing is not necessary anymore. And in that case, the current GIMP features are more than enough. A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function. ___ 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
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
