Wednesday, May 06, 2009

Experimental GUI For Users

As a very "back burner" project I have been experimenting with some ideas to assist our users. It has not been successful to explain file types (pdf, odt, jpg), or concepts like megapixels to most of them.

Here is what they struggle with from their perspective:

1) Sending pictures to other people via email and not getting it rejected because their email system won't accept the file size. 10 megapixel? What's that? What is 2MB?

2) Having dissimilar files and wanting to put them together into one PDF. OpenOffice reads odt's great; but PDFs only kind of load into Draw, how do I merge that together? Ok, now I inserted my 10 megapixel picture into Openoffice and used the corner handles and have made it 1 inch by 1 inch. That makes it smaller right? Why after a photo resize is the document still so big?

3) I want to use licensed software like Adobe Acrobat Pro because it lets me merge pieces together, I don't care that it's expensive and I only want to use 1% of the features.

4) Our vendor shipped us a PDF and now I need to merge it with my own odt and create a new PDF.

I have been tinkering with an idea to create a simple GUI to let them just drop and drag files (OpenDocument, Pictures and PDFs) into 12 positions and then it makes certain sizing decisions automatically. It then allows them to build a merged PDF with one click. No file managers would be found, everything is drop and drag. Maybe this is an early prototype for a module that should be in OpenOffice? A document sorter screen for putting pieces together?

I don't get to hack all that often anymore and don't know python and GTK in the manner I wish I did. I built the screen in Glade-2, and am stuck at how to activate the Buttons to accept a drop and drag from Nautilus. I know this is super simple for someone that does this all the time. If you want to throw me a bit of code in the comments, it's appreciated. I want to detect the release of the file into the button area, and then load the file path that it sends into a field that I can use for processing. I'm going to then have it build a thumbnail of the first page of that piece, and then update the Total Pages and Total Size fields so they can see how big it is as they go.

I'll blog about this GUI further when I get it actually working and have tried it with users to see how it works.

PS: No GUI Nazis please :)


Marius Gedminas said...

I once managed to implement drag-and-drop of images in a PyGtk app here: source is GPL. Email me if that's not acceptable.

Ulrik said...

nice! I like it! Merging things are useful for things like

1. Want to print one diagram and a short note about it on the same page -- but you have it in two diagrams

2. When I do presentations (easy/informal ones), I want to cut & paste parts from slides from other people, some own slides, and some single external files (think one plot as .pdf or .ps or .whatever) and put it together. So that's one use case. This leads to Bonus points for: Adding page numbers as an option!

Anonymous said...

You should use bold labels instead of frames, see:

A GUI Nazi

Kimble said...

I like it! I always have to google around for the right parameters when merging pdf's.

You might want to make the number icons a bit more simple though.. Perhaps loose the shadow.

emory.taylor said...

i like the way that you can move pages around in os x's preview. drag and drop multiple files and sort each individual page in the thumbnail view to sort them. now i don't know if evince would want to do any more than just document viewing, but plugging in odt support would be pretty awesome

Corey Burger said...

I love it. What about having a single area to drag to and then dynamically adding the stuff in a preview above?

Anonymous said...

Great idea.

Things like pdfjam and various other tools really lack a useful GUI.

But these are good free libraries for merging actually. No need for Adobe's stuff ;) But suite yourself :)

Couturier said...

Hi, Good Idea.

A couple of weeks ago, I started something similar. The application is called Couturier and is still in alpha state, but is already able to create a single PDF document from multiple input files like Images and PDFs. Plus you can create encrypted PDFs. The next major release of couturier is going to support OpenDocument too. I wrote the app using Mono and C# and the main pdf handling is done using itextsharp
Due to fact that couturier is under heavy development, binary packages are not available yet. You have to download the sources and build it yourself. Todo this follow the instructions at
Couturier at Gtk AppsYou may find this helpful.


Anonymous said...

there is an application "pdf-shuffler" which merges .pdf already!
Try it
ubuntu PPA :

Anonymous said...

Thanks for the recommendation of pdfshuffler! It won't do the odf files that Dave wanted to do, but it's really an awesome little app! Import multiple files, shuffle the pages around and export. Simplest GUI ever too!

Thanks!!!! Is there a plan to get this into debian / ubuntu? It would be a great feature to bundle at 24KB. Either that or extend this functionality to evince.

Dave Richards said...

Lots of excellent ideas and thoughts. I'm going to load pdf-shuffler tomorrow because it appears to be a very close fit. Then maybe we will bounty out the missing features. I believe that OpenOffice can export to PDF on the command line, so in theory it could accept a odt from the users perspective. Thanks!

Karl Lattimer said...

I like this idea, but wouldn't use buttons. Instead I'd create a custom widget which would look something like this (please copy and paste to a txt editor)

| +-----------+ |
| | | |
| | | |
| | | |
| +-----------+ |
| |
| Spreadsheet |
| 3 Pages |

At least, that would be for a start, in the future I would take a slightly more visual approach, dragging a file over the target area for instance, expands out that drag item into a formation of previews for each page in the document, then the pages slip into a sequence of pages from other docs, then I could re-arrange the pages regardless of which file they came from.

This is a really good way of producing "binder" style documents. Binding documents together into a printable document.

The idea does have potential :)

Nick Podges said...

Perhaps you could describe file sizes in the time it would take to send/receive, rather than physical space. Space seems to be less of an issue these days, but most users will understand time.

For example: run a quick bandwidth upload/download test.
Then, instead of listing an 4 mb pictures as 4mb, list it as "80 seconds to download, 20 seconds to send"

Then the user could select "Medium Quality (2 second download time, 8 second upload time)"

rather than "150kb."

Anonymous said...

Maybe PdfTk (
can help. It is GPL.

Brucevdk said...

Though you should be able to deduce what needs to be done to provide DnD support from the code Marius provided , here's a little snippet specifically to support drag and drop from Nautilus (can't use <pre> so underscores represent spaces):

def drag_data_received_cb(widget, context, x, y, selection, target_type, timestamp):
____for uri in
________# Do something...

____# A list of (target, flags, info) tuples
____[("text/uri-list", 0, -1)],
button.connect("drag_data_received", drag_data_received_cb)

Notet hat target specifies a string representing the drag type, flags restrict the drag scope. flags can be set to 0 (no limitation of scope) or the following flags: gtk.TARGET_SAME_APP, gtk.TARGET_SAME_WIDGET and info is an application assigned integer identifier to keep track of the target throughout the program.

For more information see: (the example is very good to see what targets are being offered when dragging).

Anonymous said...

Just found this today. Thought you might be interested...