Re: [Gimp-developer] GUI comment from an NT user
Date: Sun, 10 Jun 2001 13:40:11 +1000 From: Peter [EMAIL PROTECTED] Hello Robert, Thank you for the explanation. I can understand the problem of saving preferences if someone has several instances of an application open. Do you know what Gimp does? No I don't. The main problem isn't preferences; it's things like the history file, cookies, certificates database, and other things that change very frequently. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI comment from an NT user
From: Peter [EMAIL PROTECTED] Date: Sat, 09 Jun 2001 13:08:21 +1000 - There is the window within window concept. StarOffice and Microsoft Works both open a window containing multiple windows. I do not like those instances of windows within windows because they group unrelated applications and documents together. I would rather have Word files in a group with RTF documents but not mixed with spread sheets or database files. I personally detest this interface. It pretty much means that I can't do anything else while I'm using whatever application insists on doing this. Fortunately, multiple desktops can make this bearable, but it makes cut paste between different applications very unpleasant. Something I liked, back in the days when I was learning to tie shoelaces and program in Assembler (which is the easier of the two), OS/360 had what is effectively read only memory for applications. I know 98% of programmers, including most of IBM's, did not understand the concept, but it meant you could load an entire application in to memory, or just the frequently used bits, without executing the program, or using any variables, then reference the code from other tasks, The other tasks would then be extremely small and totally independent, as each would open it's own read/write memory for variables but have almost no code. Writing a well formed program was actually easier than writing the code typically sold by the big software companies. A 100,000 people could use well formed code at the same time and not have a single collision. I do not understand why companies like Netscape work so hard to make one instance crash other or why Jasc have one instance update other. This sounds a lot like how shared libraries (and indeed, shared text in general) work, but it's not enough to solve the problem. If you run multiple copies of an application (on most UNIX-like operating systems, and even Windows is probably smart enough these days), there will be only one copy of read-only memory, and read-write data will be copied on write. That's strictly an efficiency issue, though; it doesn't change the programming model. Netscape actually runs only one instance, with multiple windows (and multiple threads sharing one address space). You'll note that if you try to start a second Netscape from the command line with one running you'll get a warning that it won't be able to use your history, certificates, or anything else. This is because Netscape isn't able to arbitrate between multiple instances modifying the same file concurrently (or even accessing it where one instance might change something). Multi-threaded programming is considerably more difficult than single threaded programming, and I guess Netscape decided to only go so far (make the application MT, but not arbitrate between multiple instances). The problem with MT programming, of course, is that if you get the synchronization wrong things blow up in your face, usually in very hard to debug ways. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI comment from an NT user
Robert L Krawitz wrote: This sounds a lot like how shared libraries (and indeed, shared text in general) work, but it's not enough to solve the problem. If you run multiple copies of an application (on most UNIX-like operating systems, and even Windows is probably smart enough these days), there will be only one copy of read-only memory, and read-write data will be copied on write. That's strictly an efficiency issue, though; it doesn't change the programming model. Netscape actually runs only one instance, with multiple windows (and multiple threads sharing one address space). You'll note that if you try to start a second Netscape from the command line with one running you'll get a warning that it won't be able to use your history, certificates, or anything else. This is because Netscape isn't able to arbitrate between multiple instances modifying the same file concurrently (or even accessing it where one instance might change something). Multi-threaded programming is considerably more difficult than single threaded programming, and I guess Netscape decided to only go so far (make the application MT, but not arbitrate between multiple instances). The problem with MT programming, of course, is that if you get the synchronization wrong things blow up in your face, usually in very hard to debug ways. Hello Robert, Thank you for the explanation. I can understand the problem of saving preferences if someone has several instances of an application open. Do you know what Gimp does? My preference would be to keep the preferences from the last instance closed and just throw away anything from another instance unless the user specifically applies the change to their profile. If someone had open instance3 A and B, and manually saved a setting in A, I would have an option to save as default for future sessions. Instance B would detect that there was a default set and not save over the top. If the value is not flagged as a default, then B would write over it when B closed. The only instance I can think of where I would want multiple instances updating each other, is when I create a new brush definition in once instance, and want it immediately available in all others. I certainly do not want to change the current selection in the others, which is one problem with PSP. In the Windows world, and a few others, people have a hard time because they use objects and other techniques to make their code fuzzy. Like all fuzzy logic systems, it is hard to see what is happening so is hard to test. When they move an application from Windows to NT, the application users start finding millions of errors caused by data mixed in with code, data not defined as read data versus update, system data avaulable for update by users and an endless list of similar style design and coding faults. I worked on a number of projects to fix n-tier applications by reducing them to 2-tier or 1-tier. If some of those n-tier systems were buildings, they would have been building from the roof down. Do you know of a good, simple explanation of GTK? One that has diagrams and stuff that can be read and understood without knowing C? If I had to build a house using plans written in C, the electricity outlets would produce water and touching a kitchen cupboard knob would turn all the windows blue :-) Peter ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI comment from an NT user
Raphael Quinet wrote: Yesterday, I wrote: Hmmm... Maybe I should re-post this as an article on Advogato? That's what I did. You can find the article here: http://advogato.org/article/287.html Some of the replies are interesting, even if they would be a bit off-topic for this list. -Raphael The article's comments are interesting and show that people are using MDI for at least 4 different concepts. - There is the Microsoft MDI API. I have not tried to use it in a program so cannot comment. - There is the window within window concept. StarOffice and Microsoft Works both open a window containing multiple windows. I do not like those instances of windows within windows because they group unrelated applications and documents together. I would rather have Word files in a group with RTF documents but not mixed with spread sheets or database files. - There is the multiple document in one window approach. Opera opens multiple web pages in one window so, while I prefer Opera to Netscape, I tend to open unrelated web sites in Netscape so each site appears as a separate selection in the main toolbar. The opposite is true for email, where having all email documents open in the one window lets me very quickly scroll through the junk mail. - There is the docked and undocked toolbar approach. I do not call a tool a document, but some people do, and some tools open complex windows that would qualify as documents in their own right. I like a document appearing with all the tools applicable to the document. Netscape does a nice job by letting read email within the email application window with all email application tools in the toolbar, or I can click on an email and have it open in a separate window with just those tools that relate to individual email. I like that approach and in PaintShop Pro (the release I use), simple tools stay docked, complex tools pop open an undocked settings window. While the PaintShop Pro approach of popping up windows is nice, there are multiple images in the window and the one setting always applies to all images. There are occasions when I want to apply the same action to all the open documents so having them all in one window with one setting the for tool is great. There are also occasions when I have open several groups of images, with each group containing several images (or dozens of images) and I would like a tool setting to apply to just one group. In that case I can open several instances of PaintShop Pro, have a group of images in each instance and set the settings individually. Unfortunately that release of PaintShop Pro uses one internal setting and a change to the settings in one instance will be used in all instances, even through the tool settings display continues to show the individual setting. As another instance of good and stupid programming, an abnormal termination of one instance of Netscape, will terminate all instances of Netscape while blasting away one instance of PaintShop Pro will leave all the other instances working happily. In Apache, a big change in release two, is to support both NT's tasking and multithreading so an administrator can run separate Apache tasks for reliability while using multiple threads for performance. It would be nice to have all applications that sophisticated so separate instances of Netscape can survive the failings of other instances and PaintShop Pro will not change settings in other instances of PaintShop Pro. Something I liked, back in the days when I was learning to tie shoelaces and program in Assembler (which is the easier of the two), OS/360 had what is effectively read only memory for applications. I know 98% of programmers, including most of IBM's, did not understand the concept, but it meant you could load an entire application in to memory, or just the frequently used bits, without executing the program, or using any variables, then reference the code from other tasks, The other tasks would then be extremely small and totally independent, as each would open it's own read/write memory for variables but have almost no code. Writing a well formed program was actually easier than writing the code typically sold by the big software companies. A 100,000 people could use well formed code at the same time and not have a single collision. I do not understand why companies like Netscape work so hard to make one instance crash other or why Jasc have one instance update other. Irrespective of the technology, I would like to open an image with it's own toolbar and settings while having a separate image open with separate settings, and, when I click on one image, have all it's tools and settings appear together. A second item, in the Windows toolbar, Netscape displays the document's title first then places the advert for Netscape second while Opera places the advert for Opera first and the document name second. Opera's approach is unbelievably frustrating with a crowded tool bar. Gimp places the document name
Re: [Gimp-developer] GUI comment from an NT user
Peter wrote: Can GIMP be started with all the windows grouped the way I want? It simply reloads the previous configuration on Linux. But I don't know about the Windows version. That way, when I am in GIMP, the whole screen is working the Gimp way, and when I am in Word, the whole screen is working the Word way. Last time I used Gimp and tried to resize a window, I ended up in the Word document (which was underneath Gimp) and had to undo a text move, as the mouse movement had translated to moving text. Basically, Windows is lacking workspaces. I don't know if MacOS has them, but my Linux desktop has 16 workspaces (separate screens). So if I open up all the Gimp windows on workspace 1, and I want to open a second program which also has a few windows, then I simply switch to another workspace and open the second program there. Go back to workspace 1 and all Gimp windows are there as they were. It seems that the problem is that Linux desktops (at least UNIX-style ones, KDE is a lot more like Windows) like GNOME and Windowmaker differ from Windows desktops. I prefer the UNIX desktop by far, since it allows me much more freedom and thus increases productivity. But Linux programs fit in with Linux desktops, and thus they don't fit in with Windows. I think putting everything into a main window in Windows isn't a bad idea. It could even have the right-click menu _also_ at the top of the main window so that users of other programs can easily find it. 2c.. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUI comment from an NT user
Can GIMP be started with all the windows grouped the way I want? All the talk about user interfaces made me think about what annoys me most. using the desktop analogy, normal Windows applications look like an organized desktop and Gimp/Apple style applications look like a messy desktop. I do not like spending my time rearranging the desktop when a computer can do that for me. I do not like clicking on the edge of a window, to resize it, and end up clicking through to the application in the window underneath. I normally run with the tool bar down the side of the screen and it some times runs in to two columns (that means more than 40 applications) despite many of the applications, like Opera, running multiple windows within the one NT window. If I replace one instance of PaintShopPro, with perhaps eight images open, with Gimp, I end up with one tool bar item expanding to 12. I run every application full screen and most of the applications open with the screen the way I left it last time. Some applications let me save a layout and set that as the one I will get every time I open the application, no matter how messy it was when I left it. I would like a way to open Gimp so it is equivalent to a Windows full screen application with each tool bar docked. That would mean having one big window containing the image and the other windows as subsets of the main window, placed down the left of a vertical image and across the bottom of a horizontal image. That way, when I am in GIMP, the whole screen is working the Gimp way, and when I am in Word, the whole screen is working the Word way. Last time I used Gimp and tried to resize a window, I ended up in the Word document (which was underneath Gimp) and had to undo a text move, as the mouse movement had translated to moving text. If I could fill the screen with Gimp, I would not care if the application had a slightly different approach to other applications, as I would not be mixing the two on the same screen. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer