Typical window sizes

i’d like to know what sizes other people typically run their Gramps window. if you have a setup to run it at some specified size, i’d like to know that size with the word “exact”. if you always manually resize it after the window opens then just estimate the size and say “estimate”. if you run it full screen then could you give me the screen dimensions in pixels. thanks in advance!

(Please include your Gramps version and Operating System)

1600x900 full screen.

http://gramps.1791082.n4.nabble.com/POLL-What-display-resolution-do-you-use-td4678032i20.html#a4678069

Poll from 2016 mentions

At the moment, Gramps is designed to be usable, although it may not look
best, on 800x600 resolution displays. …

Gramps is used by people with old computers and small screens.
It is asked to the developers to have gramps window size of 800x600 max.
After that, you can use it in full screen or resize it.

1 Like

I’ve two 3440x1440 curved screens. I use DisplayFusion Windows software as complementary screen manager. When using Gramps, I use it to cut them into four virtual screens:

On left monitor:

  • 1/3 virtual screen (1290x1440): tools, gramps gramplets, …
  • 2/3 virtual screen (2150x1440): Gramps

On right monitor:

  • 2/3 virtual screen: documents I’m working on using gramps
  • 1/3 virtual screen: complementary documents like DWR of people I’m working on

If needed, I can shift-click on reduce/enlarge icon on gramps window to make it using full left monitor screen:

2/3:

Full screen:

1 Like

I think this can be done with Windows Powertoys to, and you can configure it to always open the software in the same grid…
I have only tried it out a little on one 4K monitor, and it seems to work well on one…
Powertoys are free open source

2 Likes

macOS, display logical size 2048x1152, Gramps main window 1536x1080 (3/4ths wide, full height between menubar and dock).
I have second display that I’d like to use for some windows, but Gramps doesn’t work well in macOS multiple displays system so all windows have to stay in this single display.

is there any actual data on this? I’d like to know who’s running a system that has a max display of 800x600 in 2020.

I run it at max size (not full screen) on my mac laptop, so a logical size of 2880 x 1800 (minus the menubar’s 43(?)).

A few things you might not be aware of:

  1. The 800x600 size is a guideline re-affirmed (just a couple months ago) by the Project architect
  2. the limit means you can expect the interface can run at 200% size – very helpful for older or tired eyes.

The reason that this was recently revisited was specifically because some Preferences layouts had grown clumsy & large. The tighter screen allocation forces people to plan more carefully.

Looking at some of the Reports options screens, that is a desperately needed constraint. (Look at the 6 tabs of the Complete Individual Report. They are… chaotic.)

Looking to odd implications, the limit also means a straight port to a small smart phone is more viable. Besides the obvious library issues implicit in any OS port, it obviates the absolute requirement for a mobile layout. It really only leaves the context menu interface, hotkeys & drag’n’drop as major roadblocks.

1 Like

Not sure how that’s relevant to the question of how many people actually use it at that size. Do we know?

  1. the limit means you can expect the interface can run at 200% size – very helpful for older or tired eyes.

Doesn’t this argue against using 800x600 as a maximum? If people are using doubling, then they can show 1600x1200. And it suggests to me that there should be larger-font themes, with bigger windows, not smaller. I’ve bumped up the font size on mine, for example.

Looking at some of the Reports options screens, that is a desperately needed constraint. (Look at the 6 tabs of the Complete Individual Report. They are… chaotic.)

If people are designing bad reports, that should be fixed by making better reports, not by imposing some constraint elsewhere.

PS On that report I see two panes that should be one (“Include”), and a huge waste of space at the bottom of each for what should be a printer preference, not one for the report.

the limit also means a straight port to a small smart phone is more viable

Porting a desktop app to a phone without overhauling the interface is a really, really bad idea. For one, a phone defaults to a portrait, not landscape orientation, but that’s just the start of it. There are a lot of things to do. I really hope that’s not a plan.

(post deleted by author)

The reason that it is pertinent is that the decision has recently been re-visited. Revisiting a decision too frequently is counter-productive.

As for … how many use various screen size of configurations? … We don’t have a mechanism to gather how many users there are in various OSes. Gathering hardware configuration statistics is a pipe dream. A survey on this site or the maillist would miss the vast silent majority.

First ports tend to be done by confused people without any support – blundering through on their own. No official assistance because the project takes ZERO control of porting… just the main code. The 1st pass of any port tends to be bare bones.

As for myself, I’d be OVERJOYED to have a straight port that runs on my Android Smart Phone. Even if it were crippled or Read-Only.

This is based on the mistaken impression that there is a tightly managed development cycle.

The Gramps-Project architect does not pursue porting projects. They give direction on developing the core code. They try to ensure each new feature can be adapted the OSes that have proven developers who have delivered a port. The guidelines they follow are from the GTK+ toolkit, Tango icon design & Python 3.

If you don’t like the direction of the gift someone makes with a port, make a suggestion. But rather than be upset if it isn’t picked up, organize your own team to generate a development fork. If it is successful, it could change the established future of the ports for that OS.

Gramps users are not always geeks with last computers and very big screens or multiple screens.
We have also old people managing their genealogy with old computers working on windows XP or old linux. If you have window size larger than that, they cannot access the OK, cancel, Help buttons.

This is not a problem if you have larger screen as you can resize the windows or gramps.

2 Likes

I totally know that, and no, its not based on that impression at all.
I am just saying that the reason for the 800x600 limit on gramps is because phones is flawed, I am not saying there arent other good reasons for it.
What you are saying there yourself is also another reason why phones as an argument is flawed becuase as far as I know, there arent any current version of gramps on phones, so no one dont have to think about how other people can continue to port gramps to it?

I did not really suggest something new? I just said that if someone had an idea for gramps for phones, just directly porting it would not get much traction, aka more like saying I think that idea would be bad. If someone still decide to do it, it wouldnt affect me. If they do it only for themselves only I dont care about that.

If I put up a suggestion and it doesnt happen, I will never be mad, but I have not done so in this post.

I never said that it was a reason… just a bonus

I wouldnt even think you can consider it is a bonus personally.
But that is my opinion. You can have your own.

Maybe you think that because you haven’t been looking for the upside! There are always good possibilities to see.

Unfortunately, many of your postings have been demotivating people volunteering their time to answer you inquiries. Try to see the good intent, please?

2 Likes

See upside? I do see the upside of having gramps on smartphone, but not as a direct port.
(I do understand the argument of people with old screens btw)

Many of my post have been demotivating? I dont think they have. Well, maybe exactly this but not many as I remember. But If I miss something maybe I will learn if its pointed at, maybe my own insight in to how I write things isnt the best. Anyone can PM me any time.

Ok. Why don’t we both work on it?

I try to comply with the wiki guidelines, we only document what IS (not will be in the future) and try to work within the constraints of the BD and design guidelines.

The ideal goes into the feature requests (MantisBT), Ideas (Discourse) & Proposals (GEPS in the wiki)

I also work on publicizing workarounds and alternative approaches.

But my style is, and always will be, leaning toward the Socratic method.

2 Likes