Document Properties.
- From: Pat Suwalski <pat suwalski net>
- To: evince-list gnome org
- Subject: Document Properties.
- Date: Mon, 09 May 2005 00:37:51 -0400
Hello,
I've been meaning to design and implement a Document Properties window
for evince. I was just getting to it when Emil beat me to it. He
implemented a window very similar to the one in gpdf, proposed by Bryan
Clark in Bug #164843.
While this works quite well, it becomes a tabbed interface that will not
play as nicely with a Nautilus properties window as something that will
fit in one tab sheet. If tabs are eliminated we either have a huge
dialog or hide some information )not desirable).
As such, I came up with a solution that I would like to suggest seems to
solve this issue in a rather clean way. I propose using a two-column
GtkTreeView.
While the idea may seem whack at first, it offers the benefits of:
- hiding advanced information via a initially collapsed branch
- implementing a slightly cleaner approach to the problem of long
strings in the metadata (gpdf stretches the window)
- organizing information in one tab, good for nautilus props
The first column would contain the labels (Author, Producer, etc), the
second would contain the value.
To clarify, the tree I'm describing could look like this (first column
only):
- Title
- Subject
- Author
- Keywords
- Creator
- Producer
- Created
- Modified
- Security
- Number of Pages
- Advanced
- PDF Version
- Optimization
- Font 1
- Font 2
- etcetera.
As mentioned, the "Advanced" branch would be closed at start.
I believe this format could work for the data structure we are dealing
with. I could probably take Emil's code and give this a shot without too
much effort.
--Pat
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]