Include guards need to be unique within GParted code and all included
library header files.
http://en.wikipedia.org/wiki/Include_guard#Difficulties
Use this model for all include guards:
#ifndef GPARTED_FILE_NAME_H
#define GPARTED_FILE_NAME_H
...
#endif /* GPARTED_FILE_NAME_H */
Closes Bug #539297 - Make include guards unique
The details view refused to use additional space, even after the window was
expanded, instead continuing to use the scrollbars. Now resizing the
window will be allowed regardless of the state of the details expander, and
the details view will expand to use the extra space. Also request enough
initial width to not need a horizontal scrollbar.
Closes:
Bug 602635 - list of tasks in apply dialog does not expand to the available
vertical space
Bug 662722 - Increase default width of "applying..." dialog to include the
"Details" status icons
Interested operations can now connect a signal to their OperationDetail
to be notified of a cancelation request. The internal copy/move code
will now cleanly stop on cancelation, allowing the partition to be
rolled back to its previous state. This makes canceling a move
perfectly safe.
After clicking cancel, the button changes to "Force Cancel" and is
disabled for 5 seconds. Operations that are safe to cancel will do so
and those that are not will continue to run. Clicking force cancel
asks operations to cancel, even if doing so is unsafe. For the
internal copy/move algorithm, canceling is always safe because an
error results in a rollback operation. Canceling the rollback is
unsafe. For external commands, filesystem modules may indicate
that the command is safe to cancel or not. Canceled commands will
be terminated with SIGINT.
As a result of the new safe cancel vs force cancel distinction, the
scary warning about cancl causing corruption has been moved to
after clicking the force cancel button.
Part of Bug #601239 - Please allow 'Cancel after current operation'
Win_Gparted and Dialog_Progress were creating threads to perform most
functions in the background. Most of the time, the only reason the
threads blocked was to execute an external command. The external command
execution has been changed to spawn the command asynchronously and wait
for completion with a nested main loop. While waiting for completion,
the pipe output is captured via events. In the future, this will allow
for it to be parsed in real time to obtain progress information.
Those tasks in GParted_Core that still block now spawn a background thread
and wait for it to complete with a nested main loop to avoid hanging the
gui.
Part of Bug #685740 - Refactor to use asynchronous command execution
Dialog_Progress was using pthread_create() so that it could later
pthread_cancel() the thread. pthread_cancel() is wildly unsafe and full
of errors. Changed to use Glib's threads like the rest, and only cancel
between operations. Because it can take some time to cancel, disable
the cancel button once it has been clicked once.
Bug 601239 - Please allow 'Cancel after current operation'
Win_Gparted and Dialog_Progress were looping on Gtk::Main::events_pending()
and iteration() with usleeps in between. Use a full mainloop instead and
a proper timeout to trigger pulsebar updates instead of usleeps.
Part of Bug 685740 - Refactor to use asynchronous command execution
Some classes contained private attributes which were used only by a single
member function. Such items were moved to the corresponding function implementations
to stress their limited usage scope.
A few unused variables were also deleted.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Restore copyright entries by original author to those of his last
known repository commit titled "released gparted-0.3.4 on
LarryT's request." on Feb 25, 2007.
Add my own copyright entries for files in which I changed source
code. Files in which I only made spelling changes do not have my
copyright entry added.
* include/Dialog_Progress.h,
src/Dialog_Progress.cc: Show number of warnings after all operations
are completed. Also urge people to save their details in case of
error.
* include/Utils.h,
src/Utils.cc: added format_time()
* include/OperationDetail.h,
src/OperationDetail.cc: keep track of elapsed time between
STATUS_EXECUTE and STATUS_[ERROR|SUCCES]
* include/Dialog_Progress.h,
src/Dialog_Progress.cc: show elapsed time in the details per (sub)
process
* src/GParted_Core.cc: use Utils::format_time()
* improved errorhandling a bit. At the initialscan we store
errors/warnings now in a list per partition and show the in the
partitioninfo dialog.
While executing an operation we collect all libparted exceptions in
a list and attach this list to the operationdetails when everything
is done.
* include/Dialog_Progress.h,
include/Operation.h,
src/Dialog_Progress.cc,
src/GParted_Core.cc: show warning in progressfeedback if a certain
action is n/a. Of course we only allow these actions if the results
are non-lethal.
* Use ped_device_read and ped_device_write instead of 'dd' to copy
filesystems.
Modified progressdetails to provide more detailed feedback about a
process.
Basicly these were all changes to the infrastructure to make the
incorporation of the 'move-code' a bit easier.
( sorry, not in the mood to list all affected files ;)
* src/Win_GParted.cc: removed warning about busy device. It's not
really needed and it confuses people.
* include/Operation.h: set default status of operationdetails to NONE
* include/Dialog_Progress.h,
src/Dialog_Progress.cc: implemented export of operationdetails to
external file. This can be very usefull for debugging. (#329968)
* use Glib::get_tmp_dir() instead of hardcoding it as '/tmp'
* use Glib::find_program_in_path() instead af a system/which combi
* display current device in windowtitle
* added detailed progressfeedback. It still needs some polishing, but
is already far better then the old situation. And what's more, it's
finally threadsafe :p
* Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and
adding support for other filesystems should be a piece of cake now (hope that's true :P)
It still needs a lot of love, but the foundations are laid =)
Mike Fleetwood