search

anxb26 / fritzing

Automatically exported from code.google.com/p/fritzing
1 stars 1 forks source link

The progress bar for autoroute, save, load, and export should be in a modal progress window #368

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Now the export to DIY is no longer exporting rastered images, but just svg is 
already much faster. 
Still it is expected that complex sketches will have long saving times and long 
exporting to pdf / diy 
/ etc time.

If exporting is taking longer than a couple of seconds, a progress bar would be 
greatly appreciated.

Original issue reported on code.google.com by dirk.van...@gmail.com on 11 Dec 2008 at 9:39

GoogleCodeExporter commented 9 years ago 
For saving and exporting, it could first do a simple count of the elements, and 
use this as the incremental 
progress of the progress bar.

The saving and exporting progress bar would best be an element in the sketch 
window itself (instead of being 
in a separate window). It should go in the status bar on in the tool bar (near 
or replacing the zoom menu).
The autoroute progress bar should be in the same position (in the status bar or 
tool bar near the routing 
status text.)

This area needs to be better designed, so it can fit the different status 
texts, the progress bar, (maybe the 
zoom scroller), and a cancel button to abort autorouting.

Original comment by dirk.van...@gmail.com on 12 Dec 2008 at 3:12

GoogleCodeExporter commented 9 years ago

Original comment by dirk.van...@gmail.com on 12 Dec 2008 at 3:13

GoogleCodeExporter commented 9 years ago 
r2161: autoroute progress and cancel button are now in the status bar.  There 
is some
graphical funkiness I didn't try to deal with.

Original comment by irasc...@gmail.com on 3 Jan 2009 at 10:22

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 3 Jan 2009 at 10:57

GoogleCodeExporter commented 9 years ago 
This confuses me as a user, especially on a slow machine.  The one that freaks 
me out
the most is opening files.  I'm used to a modal window progress bar that stops 
me
from trying to mess with anything sensitive before it's done.  If you're saving 
or
loading and you can (or get the impression that you can) move parts around, draw
traces, etc, you may be in for some nasty surprises.  

Non-modal progress bars are really nice for things that can run in a separate
background thread, like rendering a video, compiling or importing a file.

Autoroute, save, open and export depend on state staying stable.  If a user 
makes
changes while these processes are under way, they may be angry or confused when 
their
changes are not incorporated into the output.  We may also discover some nasty 
bugs.

I don't have a specific UI vision in mind but I think these need to be somehow 
modal
and obvious.

Original comment by brendan....@gmail.com on 24 Feb 2009 at 3:48

GoogleCodeExporter commented 9 years ago 
I agree to some extent. The progress bar is currently hardly visible, and 
especially 
the important functionalities it gives for the autorouter (skip, cancel) stay 
unnoticed.
Modal windows are pretty ugly, though. It's for instance nice that one can zoom 
while 
the autorouter progresses. Also, modal windows always let me feel overruled by 
the 
program.
Instead, I would vote for moving the progress bar up somewhere, in the toolbar 
or just 
above it. To prevent the user messing around, the mouse cursor should show the 
"waiting" symbol.

Original comment by andre.knoerig@gmail.com on 24 Feb 2009 at 5:01

GoogleCodeExporter commented 9 years ago 
For the open and save progress bar I could see a modal window work well too. In 
the case of the mac, that 
window would be a sheet, attached to the main window.

For export and autoroute I would still rather have the progress bar as a small 
bar in the status bar or the tool 
bar as I would like these functions to be not modal, interactive possibly, but 
defintely as a background process.

The exact design (coloring, placement, ...)  or the progress bar is not yet 
done of course.

Original comment by dirk.van...@gmail.com on 25 Feb 2009 at 11:25

GoogleCodeExporter commented 9 years ago 
renaming this: having the progress bar in the window was a mistake

Original comment by irasc...@gmail.com on 19 May 2009 at 5:48

GoogleCodeExporter commented 9 years ago 
Issue 476 has been merged into this issue.

Original comment by irasc...@gmail.com on 19 May 2009 at 5:48

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 19 May 2009 at 11:38

GoogleCodeExporter commented 9 years ago 
Issue 367 has been merged into this issue.

Original comment by irasc...@gmail.com on 19 May 2009 at 11:38

GoogleCodeExporter commented 9 years ago 
Added modal dialogs to save, load, export, and autoroute.  One problem is that 
these
dialogs need calls to QApplication::processEvents() in order to update.  
Autorouting
has had these calls pretty well integrated, but none of the other functions do. 
 May
have to run some of these processes in a separate thread, or figure out a way 
for the
dialog boxes to update themselves, based on some internal timer (I'm not sure 
about
this approach, because I think all UI events occur in the same thread, so even 
if you
call update on a timer, the actual repaint won't happen.)  Still, even a dead 
modal
dialog box is probably better than nothing.

Original comment by irasc...@gmail.com on 20 May 2009 at 3:18

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 20 Sep 2009 at 6:35

GoogleCodeExporter commented 9 years ago 
Issue has moved to new issue tracker at github. Please continue the discussion 
at https://github.com/fritzing/fritzing-app/issues

Original comment by andre.knoerig@gmail.com on 23 Sep 2014 at 3:37