Hi all! Tobias Jakobs wrote : > On Mon, Mar 30, 2009 at 00:30, Nathael Pajani <gimp@xxxxxxxxxxx> wrote: >> These are dockable. And we can create as many windows as we want, with groups of >> these tabbed inside. This is customization. >> The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable as >> well. > If you make such suggestions please always say why. Right. Because I do not see why there are now two windows at startup. Yes, you pointed to the wiki explanation already. It seems you are all OK for this empty unuseful window at Gimp startup or when the user closes all image windows to bring back it's desktop space for something else. With screens becoming wider, a vertical toolbox is not too much space wasted, but that big empty window is here for nothing. You even had to specify what it should look like for it not to be mistaken for an image window. This was impossible with the toolbox window. And then, using the toolbox window to open a new image seems OK to me, while using an existing image window is just incoherent. >> But then I do not see the merit behind having an empty window when you start >> gimp, with most menu being empty. >> It's it not being here but still taking up the space that is strange: >> http://www.nathael.org/Data/unused_menu_space.jpg > That is not the space that was used for the menu, but a new space that > was added after removing the menu to indicate that you can drop images > to the toolbox like you can drop images to the "No Image Window" (NIW) So, a duplicate space, and as we can drop in the tool selection part, it's mostly an extension of this space, so taking up space for not much. > If the complexity increases logarithmic or linear is not that > impotent. But I don't understand, why you are trying tu discuss facts. > Every option is expensive. It costs time in programming, testing, > documenting, supporting ... And ? Gimp is not a "paint". I thought free software were not bound to create releases in time at the lowest possible cost. >> Once again, I'll use the kernel as an example here: I won't bother counting the >> number of options and the possibilities resulting, I'll just state that it's the >> biggest piece of code I have ever seen, and still the most reliable. >> Are kernel programmers "superhero" ? "genius" ? > As a lot of other people already told you, you can't compare the > kernel with GIMP. Just have a look at the number of developers. There > are ~10, perhaps even less, active GIMP developers and no one is paid > for working on GIMP. Ok, I'll drop this comparison. And I won't comment on the number of gimp developers, but try not to have it decreasing further. And Gimp being free software, you can call on contributors... But some seems to wait for it to be a phoenix... >> Another example I'll use as some spoke about it previously: Gnome. I'll not >> bother counting the options you can find in gconf either. Still, gnome is stable >> (from my point of view at least, but most will agree) and even if it's not a >> perfect display manager, I think it's a very good one that manages to perform >> it's task. >> And the Gnome example is most accurate, don't try saying the contrary this time: >> it uses GTK, and it's also a GNU project. >> > But it's not one program. If you are looking for a programm to compare > GIMP with have a look at OpenOffice, Inkscape, Blender, Krita... Ok, I'll use one of your proposed examples: OpenOffice Won't bother counting the options either. >> Right and wrong. >> Right, the UI must not come as an afterthought. >> But the UI is not the main part of an Image manipulation program, it's here to >> give access to it's capabilities. > Have a look into the code, the UI is the biggest part in GIMP. The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? Even, both parts might be independent and many UI being pluggable to the image manipulation part. >> So designing the UI first is just silly. Both have to be thought in parallel. > Of cause this in reality not an linear process, but an interaction > between the developers, the UI designers and the users. Right. David Gowers wrote: > -- this is what led to the current form of the free-select tool -- but > the whole idea of an application is to provide capabilities to the > user .. the interface should not be dependent in any way on how the > feature is actually implemented, just that the way it's implemented > should be reasonably straightforward and plain. Right also. But once again what in here prevented the designers from creating two tools? especially when selections can be summed up using different select tools? But maybe we should stop arguing on this point, as each argument you try to bring in is an argument for my point of view, or has no relation to the point you try to defend. Maybe I'm having you loosing too much time on these emails. > The UI actually is the main part of an Image manipulation program; NO > at least, it's the main part of GIMP. NO again, because you are confusing it's goal, and the number of lines of code related to each part. > I can quote Sven as saying that the majority of code in GIMP deals with UI, > and my own investigation of GIMP code confirms this. I did not investigate, so I'll rely on you, and I can understand this very well. But it doesn't make the UI any more important. Tobias Jakobs wrote : >> One suggestion (not from me but which pleases me): have the main menu dockable, >> as are the tools menus. > Yes, that is a valid wish and was already discussed some time before. > The problem is, that the toolbox was the main window and so a little > bit special. Removing the menu out of the toolbox and adding the NIM > was the first step to make the toolbox a little bit less special. OK, but then I do not understand why the toolbox being the main window prevents the menu from becoming dockable. >>>> * About the lasso tool : >>> [....] >>> With adept use of the new tool, the only common usage of the old tool >>> you lose out on is single-stroke selections -- it is possible to make >>> them, but harder; more often I end up pressing ENTER to close the >>> shape, so the difference OLD versus NEW is 'click-drag' versus >>> 'click-drag, ENTER'. >> Ho, very nice UI improvement ! >> How are we supposed to discover this ? > Have a look into the statusbar. Nothing about pressing ENTER in the status bar. (in french at least) Not before you have clicked somewhere to try getting rid of this polygon behaviour. >> Nice to know anyhow. I don't mind having to press enter to finish, but I cannot >> discover it. > What have you tried to discover it? I was told in a previous mail. >> If you plan for good UI, then a small tooltip saying "press enter to close the >> selection" (of course with a setting to enable/disable tooltips, or it would not >> be fun) would be a UI improvement. > No, tooltips are not a good idea, because tooltips would hide parts of > the most impotent thing in GIMP the image. That's why the statusbar is > much saner for GIMP. Yes, you're 100% right, and these info are often good ones, even if in this case they are not complete and, in the french translation, not even accurate. >>>> And then, on the same point, you create a new menu entry called "create" but the >>>> "New image" is still outside of it ! >>> This is a compromise due to how frequently the user will use 'New Image' >> I use it less than 10% of the times I use gimp... and I must not be the only >> one. But I use screenshots and scanning very often on the other hand. > An other reason for keeping the 'New Image' at top is, that it is the > recommended place from the Gnome HIG. And ? Gimp will become GNOME dependent ? > (And the Apple HIG) Apple dependent ? >> From my experience, when you are redesigning something, it can be done accross >> minor releases (2.6.6 to 2.6.7 and then more parts for 2.6.8, and some more >> again for 2.6.9 and so on. > GIMP follows here the good old GNU version theme > major.minor.maintenance. The last number is for bugfixes and > translations only the second number for API compatible releases. OK I thought 2.2, 2.4, 2.6, were major releases. (They look like it from outside, with the new splash and so on). >> Releasing is not a requirement (or so I think). If there is job to be done, you >> do it before releasing a major release so that ALL the changes are done for the >> major release. >> When all of you are saying "we are redesigning the UI" but here is only one >> part, I feel like it is a work in progress. This is completely contradictory to >> performing major releases. You do not release a work in progress as a major release. >> Am I the only one with this point of view ? > Yes, because at least I'd like to have a new GIMP version every 1-2 > years and not every 10 years. You mean a major release ? But still, being a debian user, I like their ways (Or am I a Debian user because I like their ways ?) and think that it should be so for all free software. What need to have new versions if they are "ongoing job" ? _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
