Closing a drawing
JoopN opened this issue · 15 comments
When I want to close just the drawing then I also close FidoCadJ. There is not an option for just closing the drawing, let FidoCadJ running and choose an other drawing to work on. At present it works, but at the background you also close Java and restart Java and FidoCadJ just for an new drawing. Up to now the Pi has no problems with it, but its not a nice way in my eyes.
What do you mean, exactly? Close the drawing and keep FidoCadJ running? This is something that I would find normal as it is exactly what happened with classic Macintosh programs. However, this is not something users from other operating systems are used to and for this reason FidoCadJ does not behave this way.
By the way, I recall people leaving tens of applications running in background (on MacOS 8-9) without realizing it, until they ran into memory issues.
For this reason, more recently, most macOS applications tend to exit, when the last open window of the program is closed.
On Windows there was (Is still used?) the multiple document interface (MDI) paradigm, but FidoCadJ does not follow this paradigm.
Yes, closing the drawing, keep fidoCadJ running and do something different like starting another drawing or make a new one. We're talking Java. And that's growing and growing, so shut it down and start direct again can give the trouble that it still be busy with closing and that can give errors. In my view you just have to add the option close drawing.
But how can you access to the menus to load a drawing let's say on Linux if you do not have a window open?
??? In my mind when I just close only the drawing then FidoCadJ is still up and running with its menu. So you go to the menu File and then Open File. You mean this with Window? FidoCadJ stays in the taskbar of the computer, you could see it as a tab and therefore see it as a window, but I don't think that way.
Can you please post a screenshot of the situation where all windows are closed? I do not think I see what you mean on Linux or on Windows (albeit I see it very well on macOS).
All windows closed gives at best desktop background on my system, most Linux users only have a prompt. But (attached) screenshot is FidoCadJ just started. Next step is to choose or a new drawing or an existing. And when I close just a drawing this is the point where I think I should end and not on the desktop of my computer and having to start up FidoCadJ again. But again this is the way I work, up to now the existing way does not give a problem.
So you basically suggest that when the last window of FidoCadJ containing a drawing is closed, FidoCadJ opens a new one with a blank drawing? Is this the standard behaviour of GUI programs in Linux?
No, just returns to the position when you start FidoCadJ. Now you have to decide if you want to open a new drawing or open a fidocadj-file. I think it will go the same way on a Mac. And this is also the screen or start or position (I don't know how you call it reading your comments) where I want to go back when I close a drawing (and no other drawings are open) and have to decide then if I want to open a new drawing or if I want to open an existing drawing. I don't know what the standard behaviour is in GUI programs in Linux, some do the same as in Windows and some do it different. But almost every program I have used have the option for closing the document and not close the program, see Word or Excel. So its not a Linux thing, I can try in Windows or OS/2 (but that is a version which can run in Java 6).
When you open FidoCadJ, it automatically shows a new blank drawing.
If not, when there is no window shown in Linux, where is the menu shown?
Okay, I thought it did has nothing, no drawing, just menu bars and an empty field. The reason why I thought so is that if you exit you not get the question for saving the file. Also if you want to open an existing drawing you have to go to the menu. My wrong, but the way it exits is to stay. When I do that often, open and closing drawings, then I sense that sometimes FidoCadJ is going slower. But its far too soon to say that this is FidoCadJ to blame, could also be Java, after all each version for each OS of Java has to be (re-)compiled for that particular OS and with it things can go wrong with addressing the memory space in a particular OS. I use many Java programs and if I sense that this comes into play I can start an other Java program in order to see if this is also slower then I now when its run stand alone. If yes, implementation of Java (in this case for the Pi) might has errors, if no may be FidoCadJ. This will not be easy, its also a call somewhere in the issues for Linux.
If you experience performance issues with Linux, in the past we had very long discussions and we finally concluded it may be an issue with graphic card drivers in some cases. In other cases, slowness was related to poor grid drawing code. Version 0.24.8 should be more or less OK for the latter point.
We're going off topic. But to answer your remark, I have the feeling that it is a problem in main memory, but this is in RaspBerryPi 400. As soon as I use more programs and open and close files one after another within these programs, so not only FidoCadJ (OpenJDK)!, then sometimes things are slow down, ie in FidoCadJ it will suddenly takes time to draw something from the lib, placing or dragging the element takes time. Or for the matter, Libreoffice needs more time for adjusting a picture in the document. So I don't think it is FidoCadJ or OpenJDK, but the version of Linux I have on the Pi. But need more testing for making a bug report on the forum of RaspBerry. Seems that fragmenting memory is the problem.
Should this issue remain open?
As we do have different standpoints and it seems that we can't come together I think you can close the issue.
Ok!