Re: [Gimp-developer] Another new image dialog mockup
* Nathan Carl Summers <[EMAIL PROTECTED]> [040508 03:31]: > On 7 May 2004, Sven Neumann wrote: > > Hi, > > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > I took a look at the new image dialogs on the list today, and I made > > > a few improvements. I've posted them at > > > > > > http://wilber.gimp.org/~rock/NewDialogSimple.png and > > > http://wilber.gimp.org/~rock/NewDialogExpanded.png > > > > Centering the unit menu next to the size entries does IMO look horrible > > since it deviates from the table layout of the dialog. > > A slightly ironic comment, since the centering was implemented using > GtkTable. :) > > With the units dropdowns positioned the way they currently are, it is not > immediately apparent that they apply to both of the entries. Aligning the > dropdowns with the bottom entry is especially bad because the first entry > is completely scanned before the dropdown is scanned. By aligning the > controls the way that they are, it take a lot more processing to realize > that the units dropdown applies to the entry above as well. This > processing has to take place at a very high level; it requires actual > conscious thought. To communicate less effectively, the dropdown would > have be be located in a completely separate part of the dialog from the > entries it affects. > > By far the best layout is to center the control, because then the > applicability to both elements is most obvious. The human visual system > groups all three controls together, and so it would take conscious > processing to disassociate them instead; in other words, you get the > association for free. A distant second best would be to align the units > dropdown with the topmost entry instead of the bottommost. That way still > requires some conscious processing, but at least one wouldn't have to > backtrack to find which entries the dropdown applies to. One of my comments on irc was that I'd like the units dropdown aligned with the entries for width/height, for the same reason of visual grouping. I fail to see the need for the layout of the dialog to even resemble a table. If that was an argument, one could as well argue for keeping the entry boxes of width/height, and Res.X / Res.Y, the same width, and horizontally aligned, this adds nothing but "stiffness" to the dialog. > > Using a frame for the template selection seems wrong because a frame's > > supposed to group elements. The template menu is a single element > > The problem here is that the existing layout breaks a cardinal rule of any > kind of layout: the dialog elements are not treated consistently. The > controls in the "Image Size" and "Advanced" groups are labelled with > headings, but the template control has no heading at all. This lack of > balance makes the template dropdown look like an afterthought. Originally > I simply bolded the Template: label, which made it look more balanced, but > the dropdown still looked out of place, so I indented it. >snip< > I agree that a label would make the dropdown seem less out of place, but I > left one off for the simple reason that I couldn't think of a good one. > Perhaps "Apply:" would work here? Or perhaps the heading should be > something else and the label would be "Template:" The titles of the frames can actually be seen as section headings in a text, the body of the first section in Nathan's screenshot is a single dropdown widget. I would find this quite intuitive; the reason I would is probably that I am used to read books and other written material using standard typographical means to group and organize different elements. He also seems to have added some more vertical space (air) before each heading this adds further to visual grouping and increases readability. (this might be a theme issue though). There is one issue I have with both this Nathan and Svens screenshots, The header for the 'Image Size' group and the 'Advanced' are not aligned which each other (at least not when processed by my visual system), the fact that the labels in Nathans screenshot is not directly aligned with the beginning of the word Advanced helps a little, but I would prefer to put the expander triangle 'in the margin' thereby having all the group headings aligned. (mockup from Sven's version at http://freedesktop.org/~pippin/gimp-new-image-mod.png ) /pippin -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another new image dialog mockup
On 7 May 2004, Sven Neumann wrote: > Hi, > > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > I took a look at the new image dialogs on the list today, and I made > > a few improvements. I've posted them at > > > > http://wilber.gimp.org/~rock/NewDialogSimple.png and > > http://wilber.gimp.org/~rock/NewDialogExpanded.png > > Sorry, but I fail to see any improvements in these mockups. Honestly, I would have expected you to reply in a more thoughtful and constructive manner. It's obvious that I spent some time (hours, actually) constructing this mockup, and that I didn't think that my choices were stupid, yet it really feels like you have dismissed them all out of hand. This is exactly the reason GIMP has problems attracting and retaining new contributors. I'm sure if you have asked yourself why I was suggesting the things that I was, what you would have said would have been more reasonable, or at least more reasoned. You know that I am not an idiot. You also know that I spent three months as an intern in a usability lab, so I'm not completely clueless about the topic. If you failed to see any improvements, you also failed to see why others might think that there are, and to identify the principles behind which the changes were made. Not only that, you didn't give me the opportunity to comment more on them (like I said I would) before summarily dismissing them. That is more than bad intellectual practice; it is bad leadership. That said, here is my responce to you comments. > The icon next to the memory size as well as the bold label "Memory > Required" don't add any value The icon adds value in two major ways: 1. It provides instantaneous feedback about whether memory usage would be above the threshold set in the user preferences. This is a usability win, since it allows the user to immediately fix the mistake instead of having to re-open the new image dialog after the warning comes up as a separate alert as in http://bugzilla.gnome.org/show_bug.cgi?id=21028 and the user cancels the image creation. Note that it's still a good practice to have the alert box come up as a double-check that the user wants to create an overly large image, even if they have already been warned here in the new dialog. 2. In its normal usage, the icon immediately identifies the corresponding controls as being informational and not directly manipulable. Since the general layout is consistent with other GTK applications, instead of distracting the user, it allows the user to immediately recognize that in order to get the work done, the user needs to manipulate the controls in the other sections of the dialog. It would take a higher level of processing to identify the purpose of the section if the icon were not present, or if it were not placed where it was. > wastes screen estate Screen estate is really a non-issue here. Even with the ridiculously bloated theme that comes with Glade for Windows (yeah, yeah, buy me a T1 so I can do this kind of stuff at home on my beloved Debian Sarge box instead of at work) the fully-expanded dialog is by default 344 x 521 pixels, which means that it will fit on any display bigger than 640 x 480. Actually, it will even fit on a 640 x 480 display, since the somewhat ungraceful behavior of the dialog is to clip the bottom part if there isn't enough space allocated. If your display adaptor can't do 640 x 480, you will have bigger problems with GIMP than just the new image dialog going off the screen. Since the new image dialog is unlikely to be open very long, how much it occludes other windows that are in use is unlikely to be an important consideration. Even if real estate was an issue, the mockup in total is 32 pixels longer than the screenshot you posted yesterday. The difference in real-estate usage is not that great, and would probably be mitigated almost completely if the same theme was used in both screenshots. I should note that the screenshot posted yesterday wouldn't fit on a 640 x 480 display, either. Regardless of whether minimizing screen estate is a priority for the new image dialog, given the previously discussed utility of the icon, I would argue that it is a very effective use of real estate. In fact, I experimented with several layouts for the memory required portion of the dialog. Some had icons and some did not. For those that did have icons, I experimented with the size of the icon and with hiding it when the memory requirements did not exceed the threshold. This layout was by far the most effective, and that is why it is the one that you see. It is the most effective because it is a slightly miniaturized version of the standard HIG information window layout, and so, since it is consistent with other applications, it is immediately identified by the user for what it really is. Furthermore, the icon area is designed so that it can accommodate vast changes to the size of the dialog while still being
Re: [Gimp-developer] reporting bugs on builds
Hi, Simon Budig <[EMAIL PROTECTED]> writes: > Dave Neary ([EMAIL PROTECTED]) wrote: > > Jernej's installers are a great service, and if we don't want him to stop > > (and I know I don't), and bit more tolerance is called for. Currently, we > > don't even tell people how they should report bugs against the installer, > > the bugs are just closed NOTGNOME. > > What about a component "installers" or "binary packages" where we > can put the bugs that are related to a certain gimp distribution? If the maintainers of the "installers" or "binary packages" agree to watch bugzilla for their bugs then that's probably the best we can do. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Cleaning up the wiki
Hi, as you might (or might not) have noticed, the wiki at http://wiki.gimp.org is becoming a really useful resource for The GIMP. There are, however, a few problems that should be looked at. In short words, these are look, content and configuration. Look The wiki just doesn't look like a gimp site, but a MoinMoin wiki site. At least the logo should be replace by a wilber logo. Preferably, the layout should resemble the www.gimp.org and developer.gimp.org. However, given the various problems that rose during the website move, I don't think anyone should waste time for creating a layout that will be considered inappropriate for the wiki. Content Sooner or later, the content of a wiki will become a mess. Everyone creates page names just like he wants, there are a lot of unfinished pages, duplicates, ... Just remove them, you say? Well, if I read the wiki help correctly, this is not possible without having an account to and enough priviledges on the system where the wiki is installed. Other wikis offer this in their web interface, MoinMoin apparently doesn't. Configuration Some additional, quite useful features of the wiki have to be enabled by the administrator. Mail notification, other url protocols, file uploads, ... So, I'd like to have the following questions answered: - is there anyone who feels responsible for the wiki? - does anyone feel responsible for bugs reported against the wiki? - how should theese bugs and feature requests be reported? - who has the needed priviledges to do the kind changes mentioned above? And, just in case "no", "not at all" or "no one" are the answers, what can be done to change this? Michael -- The GIMP > http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Sodipodi > http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Donation for GIMP features
Hi Michael, You might want to have a look at XNest, or the following GIMP plug-in if you are working on Win32: http://registry.gimp.org/plugin?id=3892 I don't know if there is an equivalent for Mac OS X, though. Thanks for the link. This is great, it's got a lot of what I was interested in. If the windows could be bound within the main window area that would be all the main things my friend and I were looking for atm. Kind regards JG ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: reporting bugs on builds
On Friday, May 7, 2004, 22:59:14, Sven Neumann wrote: > I was under the impression that building a GIMP installer involved > some black magic. After all there don't seem to be many people able to > build GIMP from source on win32. Once you have the mingw+MSys environment set up, building Gimp is just ./configure --prefix= && make. Getting GTK+ to compile is more challenging though (but I use precompiled GTK packages provided by Tor for now). Right now, building the installer involves make install, then running the install script from the top install directory. Since the install builder has a command-line compiler, this could be automated, too... -- begin .sig < Jernej Simoncic >< http://deepthought.ena.si/ > She who is silent consents. -- Italian Proverb end ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: reporting bugs on builds
Hi, =?Windows-1250?Q?Jernej_Simon=E8i=E8?= <[EMAIL PROTECTED]> writes: > > Because we can't do anything about the bugs. Nobody but the packager > > can. The situation would be different if the tools used to build the > > binary packages would be in GNOME CVS. That would certainly qualify > > the project for also using the bug tracker. But as long as people > > build GIMP using proprietary scripts that they don't publish anywhere, > > I am going to show no tolerance towards them. > > Not sure about what kind of proprietary scripts are you talking about - the > installer scripts were always available, though it depended a lot on my mood > where I put them (in a separate zipfile, or together with the rest of > sources). The setup compiler itself is free, too. > > To compile Gimp, I use MinGW+MSys, with no special tools. I was under the impression that building a GIMP installer involved some black magic. After all there don't seem to be many people able to build GIMP from source on win32. Perhaps the setup scripts should be kept in CVS then. Not sure if they belong to the GIMP source, probably not. But there could be a separate module. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: reporting bugs on builds
On Friday, May 7, 2004, 20:59:14, David Neary wrote: > I'm glad you joined the thread, because there's one question that > hasn't been answered yet. I've been subscribed for a while, but haven't really posted much (and I just noticed that the last 2 messages I did send never arrived to the list due to my own stupidity). > Would you like to have your installer's problems tracked in > bugzilla? I wouldn't mind this at all. -- begin .sig < Jernej Simoncic >< http://deepthought.ena.si/ > He who hesitates is last. -- Lyon's Law of Hesitation end ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: reporting bugs on builds
Hi Jernej, Jernej Simon?i? wrote: > Not sure about what kind of proprietary scripts are you talking about - the > installer scripts were always available... I'm glad you joined the thread, because there's one question that hasn't been answered yet. Would you like to have your installer's problems tracked in bugzilla? Or would you prefer us to refer the bug reporters to your page? If so, where should we send them? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: reporting bugs on builds
On Friday, May 7, 2004, 17:50:13, Sven Neumann wrote: > Because we can't do anything about the bugs. Nobody but the packager > can. The situation would be different if the tools used to build the > binary packages would be in GNOME CVS. That would certainly qualify > the project for also using the bug tracker. But as long as people > build GIMP using proprietary scripts that they don't publish anywhere, > I am going to show no tolerance towards them. Not sure about what kind of proprietary scripts are you talking about - the installer scripts were always available, though it depended a lot on my mood where I put them (in a separate zipfile, or together with the rest of sources). The setup compiler itself is free, too. To compile Gimp, I use MinGW+MSys, with no special tools. -- begin .sig < Jernej Simoncic >< http://deepthought.ena.si/ > It is much harder to find a job than to keep one. -- Becker's Law end ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Dave Neary wrote: > Sven Neumann wrote: > > "Branko Collin" <[EMAIL PROTECTED]> writes: > >>Of course, this would put the burden of triage on the GIMP developers > >>who are currently doing that, but it might avoid reporters being > >>scared away by curt WONTFIX replies. > > > > The reply is NOTGNOME and we usually ask the bug reporter to get in > > contact with Jernej or whoever built the binary package and report the > > problem there. > > By "we", you mean "I", don't you? And today that hasn't happened at least > once, the reply was simply "Your bug report is about the installer > then and thus does not belong into this bug-tracker". Well, you can't prevent anyone from reporting bugs, but the quality of the replies can be improved. Is it possible to have some kind of "canned replies" in bugzilla? So that when resolving a bug against e.g. the win32 installer as NOTGNOME, an explantory text is just one click away? > > IMO it's up to Jernej or whoever builds the binaries to > > setup a bug-tracker for it and to inform users that build problems > > should be reported there. That's what all other packagers of GIMP do > > as well. It certainly doesn't belong into GNOME Bugzilla. > > "All the other packagers of the GIMP" make money from it, and employ > people to do this type of thing, and have dedicated machines. > Jernej makes binaries in his spare time, and the least we could > do is show a little tolerance on this issue. I'm not sure if I agree or not, but I'd like to see some requirements tied to featuring installers in bugzilla. This isn't directed against anyone directly, but a clear set of rules should be created. Do you want e.g. WinGIMP or MacGIMP to use bugzilla.gnome.org? What about other Free win32 installers of GIMP? > I don't see why bugs like these certainly don't beling in GNOME Bugzilla. > It would be nice if you could explain why this is so obviously true. If you think that Sven wrongly resolved bugs as NOTGNOME, please list them. Then it would be possible to discuss the sepcific cases. Michael -- NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
On 7 May 2004, at 17:50, Sven Neumann wrote: > Dave Neary <[EMAIL PROTECTED]> writes: > > > By "we", you mean "I", don't you? And today that hasn't happened at > > least once, the reply was simply "Your bug report is about the > > installer then and thus does not belong into this bug-tracker". > > Well, I knew that I was dealing with Branko, who should know > better. The response is different when innocent users hit bugzilla. That I should know better is true but for one thing, and also it is not a good argument in its own right. I should know better when I am absolutely certain that a bug is purely restricted to a certain build. Without using a certain GIMP version in at least two different incarnations, I cannot tell with 100% certainty that some bug is strictly related to a certain build. Also, 'dealing with Branko' is not a concept known to 'innocent users' who stumble on your comments when searching for existing reports for their bugs, and may conclude that this is how you talk to everybody. You could have used e-mail to tell me that I should know better. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > By "we", you mean "I", don't you? And today that hasn't happened at > least once, the reply was simply "Your bug report is about the > installer then and thus does not belong into this bug-tracker". Well, I knew that I was dealing with Branko, who should know better. The response is different when innocent users hit bugzilla. > "All the other packagers of the GIMP" make money from it, and employ > people to do this type of thing, and have dedicated machines. Jernej > makes binaries in his spare time, and the least we could do is show > a little tolerance on this issue. I am not opposed against helping Jernej with this if he asks for help. But I don't see why he should be treated differently in the first place. > I don't see why bugs like these certainly don't beling in GNOME > Bugzilla. It would be nice if you could explain why this is so > obviously true. Because we can't do anything about the bugs. Nobody but the packager can. The situation would be different if the tools used to build the binary packages would be in GNOME CVS. That would certainly qualify the project for also using the bug tracker. But as long as people build GIMP using proprietary scripts that they don't publish anywhere, I am going to show no tolerance towards them. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Hi, Sven Neumann wrote: "Branko Collin" <[EMAIL PROTECTED]> writes: Of course, this would put the burden of triage on the GIMP developers who are currently doing that, but it might avoid reporters being scared away by curt WONTFIX replies. The reply is NOTGNOME and we usually ask the bug reporter to get in contact with Jernej or whoever built the binary package and report the problem there. By "we", you mean "I", don't you? And today that hasn't happened at least once, the reply was simply "Your bug report is about the installer then and thus does not belong into this bug-tracker". IMO it's up to Jernej or whoever builds the binaries to setup a bug-tracker for it and to inform users that build problems should be reported there. That's what all other packagers of GIMP do as well. It certainly doesn't belong into GNOME Bugzilla. "All the other packagers of the GIMP" make money from it, and employ people to do this type of thing, and have dedicated machines. Jernej makes binaries in his spare time, and the least we could do is show a little tolerance on this issue. I don't see why bugs like these certainly don't beling in GNOME Bugzilla. It would be nice if you could explain why this is so obviously true. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Hi, Simon Budig wrote: What about a component "installers" or "binary packages" where we can put the bugs that are related to a certain gimp distribution? Sure, I could do this. I'll wait to see what the feedback on this thread is first. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Hi, "Branko Collin" <[EMAIL PROTECTED]> writes: > Of course, this would put the burden of triage on the GIMP developers > who are currently doing that, but it might avoid reporters being > scared away by curt WONTFIX replies. The reply is NOTGNOME and we usually ask the bug reporter to get in contact with Jernej or whoever built the binary package and report the problem there. IMO it's up to Jernej or whoever builds the binaries to setup a bug-tracker for it and to inform users that build problems should be reported there. That's what all other packagers of GIMP do as well. It certainly doesn't belong into GNOME Bugzilla. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Dave Neary ([EMAIL PROTECTED]) wrote: > Jernej's installers are a great service, and if we don't want him to stop > (and I know I don't), and bit more tolerance is called for. Currently, we > don't even tell people how they should report bugs against the installer, > the bugs are just closed NOTGNOME. What about a component "installers" or "binary packages" where we can put the bugs that are related to a certain gimp distribution? >From time to time we'd have to clean it up so that the bug count doesn't get out of control, but IMHO bugzilla might very well be the place to track these kind of external bugs. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] reporting bugs on builds
Hi, Branko Collin wrote: However, anyone who uses a pre-compiled build cannot know beforehand what part of the bugs are build related, and what part GIMP related. Especially MS Windows users, who may not (and should not!) have a concept of build versus source distribution to begin with, may find it difficult to make the distinction. Would it be useful to devise a system in which all users can file GIMP related bug reports, whether they have bearing only on the build they are using or on all of the GIMP? I definitely agree with that. The correct thing to do with bugs reported against the installer is, IMHO, to add jernej as a CC, set the component to Win32, and then leave it alone, and open. That way, Jernej can use our bug tracker, perhaps teach us a thing or two about windows along the way, and neither he nor our windows users feel like they aren't considered good enough to be in the GIMP crowd. Jernej's installers are a great service, and if we don't want him to stop (and I know I don't), and bit more tolerance is called for. Currently, we don't even tell people how they should report bugs against the installer, the bugs are just closed NOTGNOME. Of course, this would put the burden of triage on the GIMP developers who are currently doing that, but it might avoid reporters being scared away by curt WONTFIX replies. These bugs are already being triaged as RESOLVED NOTGNOME. Changing the component, adding a CC and leaving the bug open takes as much time, and is a lot friendlier. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Re: Gimp on Slashdot
Juhana Sadeharju ([EMAIL PROTECTED]) wrote: > But maybe they are not that easy to code? Adding a vector layer to > the images should be easy if the image object is good, but the vector > manipulations can be difficult. Typically each plugin has its own > kludge way to manipulate vector objects (selection tools, crop tool, etc). > The selection tool vector drawing and the crop tool vector drawing > are not visible in other views of the same image because the framework > is kludge. > > What we need is a good old vertex/edge/polygon framework. We don't > have even the simplest systems developed at 1960s. Check out > ftp://ftp.funet.fi/pub/sci/audio/devel/constraints/sketchpad.pdf > what I mean. The Link you gave does not work. > I'm figuring out what kind of framework would be ok. Anyone > would like to help? Why isn't this discussed on gimp-devel? In fact there is a vector based infrastructure and I also believe that it is quite flexible. Simply fiddle a bit with the Path tool to get an idea how this works. Yes, it is not integrated in all the places where it should be, but it definitely is there and it definitely is quite flexible (although I am biased about that). Maybe you should look at the code before drawing conclusions like "the framework is kludge". I've put quite a lot of work into that stuff and I'd like to see at least some reasons *why* it supposedly is a cludge. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] reporting bugs on builds
I just got rebuked by Sven for reporting bugs that are strictly related to Jernej Simoncic's MS Windows builds of the GIMP. Apparently, Bugzilla is only there for reporting bugs on the stuff that WGO distributes. In a way, that definitely makes sense. However, anyone who uses a pre-compiled build cannot know beforehand what part of the bugs are build related, and what part GIMP related. Especially MS Windows users, who may not (and should not!) have a concept of build versus source distribution to begin with, may find it difficult to make the distinction. Would it be useful to devise a system in which all users can file GIMP related bug reports, whether they have bearing only on the build they are using or on all of the GIMP? I can imagina having either a 'GIMP builds' product that build related reports can be moved to, or having a 'builds' compononent. Of course, this would put the burden of triage on the GIMP developers who are currently doing that, but it might avoid reporters being scared away by curt WONTFIX replies. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] new file-new dialog
> "Austin Donnelly" <[EMAIL PROTECTED]> writes: > > > > - Add an easy way to change the image's unit. It's quite well hidden > > > in the Image Scale dialog right now. With the changes proposed > > > above, changing the image unit could become a more frequent task, so > > > it should be easily accessible. > > > > I'd suggest taking a double-click in the rulers should bring up a > "change > > units" dialog box. It should allow people to change to pixels, since > the > > most immediately visible effect of changing the image's units is to the > > rulers. > > That's not very intuitive IMHO. If we display the unit in the > statusbar, then it would probably be best to allow it to be changed > where it is displayed (and, of course, in the menu as well). I see > that the rulers do also display the unit in one way or another. > However a double-click on the rulers is something that only few users > will ever try. I also guess that only few users ever find out that you > can create guides by dragging them from the rulers. I like the idea of a pop-up in the statusbar - and I expect that's what most users will use to change the units. But if a user does double-click a ruler, how should Gimp interpret that? Perhaps it should popup a dialog saying: Ruler configuration --- Show rulers: [X] _ Image units: |- Inches | - Tip: you can create a guide by dragging from a ruler into the image I know all this functionality is available elsewhere, but it makes Gimp friendlier. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another new image dialog mockup
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > I took a look at the new image dialogs on the list today, and I made > a few improvements. I've posted them at > > http://wilber.gimp.org/~rock/NewDialogSimple.png and > http://wilber.gimp.org/~rock/NewDialogExpanded.png Sorry, but I fail to see any improvements in these mockups. The icon next to the memory size as well as the bold label "Memory Required" don't add any value, waste screen estate and distract from the important parts of the dialog. Centering the unit menu next to the size entries does IMO look horrible since it deviates from the table layout of the dialog. Using a frame for the template selection seems wrong because a frame's supposed to group elements. The template menu is a single element and in your mockup it stands completely unlabelled. I think Jimmac and Tigert did a very good jo with their mockup and I don't see much room for improvement. IMHO we should stick to it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
