DaemonForums  

Go Back   DaemonForums > Miscellaneous > General software and network

General software and network General OS-independent software and network questions, X11, MTA, routing, etc.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 10th October 2012
xmorg xmorg is offline
Real Name: Tim Cooper
Fdisk Soldier
 
Join Date: Sep 2010
Location: San Diego
Posts: 56
Thanked 0 Times in 0 Posts
Default windows/dialog boxes larger than screen

This has been a pain in my side since RedHat Linux 5.1.

It has continued on through my use of FreeBSD, and it has to do with the default window size of various dialog boxes and applications that use xorg/xwindows. Windows are often drawn offscreen if your monitor resolution is not large enough. If your screen is large enough you dont notice but back in the day I had a 1024x768 tube monitor and it sucked that i couldnt see the whole window when I opened it up

2(modern) examples
(Fedora) Emacs(using gtk) opens up in pekwm in full view then quickly resizes to larger than my screensize. The bottom bar is below the screen.

(trisquel) This one is a serious one imho. I finally got mi wife to use linux on her netbook yet being a netbook at 1024x600 it does not have a LARGE irix multiscreen monitor So when we tell it to print, the print box comes up larger than the screen vertically. the printer selection box is huge! it has space for like 10 printers when we have only 1, hehe. the system doesnt seem to let us maximize or resize i vertically(only horizantally) Also, you cant reach the bottom right corner becuase its offscreen.

My question: is there someway to force dialog boxes and apps to conform to the screen size instead of going beyond the screen size? some apps seem to be hardcoded to work with larger screens only.
Reply With Quote
  #2   (View Single Post)  
Old 11th October 2012
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by xmorg View Post
My question: is there someway to force dialog boxes and apps to conform to the screen size instead of going beyond the screen size?
Only by playing with screen resolution. Window & dialog sizes are preset.
Reply With Quote
  #3   (View Single Post)  
Old 11th October 2012
xmorg xmorg is offline
Real Name: Tim Cooper
Fdisk Soldier
 
Join Date: Sep 2010
Location: San Diego
Posts: 56
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by ocicat View Post
Only by playing with screen resolution. Window & dialog sizes are preset.
We are talking open source stuff here so preset where? for GTK is there usually a setting in dconf or is it a matter of hacking source code?
Reply With Quote
  #4   (View Single Post)  
Old 11th October 2012
Carpetsmoker's Avatar
Carpetsmoker Carpetsmoker is offline
Real Name: Martin
Old man from scene 24
 
Join Date: Apr 2008
Location: Eindhoven, Netherlands
Posts: 2,074
Thanked 198 Times in 156 Posts
Default

In PekWM, you can use the ~/.pekwm/autoproperties to force a size on start.

For example:
Code:
Property = ".*,^Opera" {
  ApplyOn = "New Start Reload Transient Workspace"
  Workspace = "2"
  ClientGeometry = "400x400"
}
Also see:
http://www.pekwm.org/files/pekwm/doc...autoprops.html

In addition, some programs accept the -geometry argument, although this seems to be less common these days ...

Quote:

(trisquel) This one is a serious one imho. I finally got mi wife to use linux on her netbook yet being a netbook at 1024x600 it does not have a LARGE irix multiscreen monitor So when we tell it to print, the print box comes up larger than the screen vertically. the printer selection box is huge! it has space for like 10 printers when we have only 1, hehe. the system doesnt seem to let us maximize or resize i vertically(only horizantally) Also, you cant reach the bottom right corner becuase its offscreen.
I have more or less the same problem. At work I have two 22" screens, I do >90% of my work on one screen (the one in front of me) and use the second screen for some status windows, our company chat, etc.
If I configure Xorg as "multi-monitor" in xorg.conf it treats both screens as if it's one huge screen, it doesn't make any distinction between the individual screens.

I don't know if you can change this behavior, but my workaround is *NOT* to configure Xorg in multimonitor mode and start it normally, it will show the same contents on both screen.
Then I manually use xrandr to setup the multi-montitor environment, this way PekWM will "remember" one screen as the "main" screen. This way it works pretty much like MS Windows (which I prefer).
This may not work with all window managers, I *think* this is actually a bug in PekWM, but a darn useful one IMHO
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

Last edited by Carpetsmoker; 11th October 2012 at 07:08 PM.
Reply With Quote
  #5   (View Single Post)  
Old 11th October 2012
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by xmorg View Post
...so preset where?
For compiled applications, resources can either be configured at compile-time or dynamically at run-time. The advantage of compile-time configuration is an obvious performance gain, whereas run-time configuration has to be parsed during execution. For the dynamic languages, most of this kind of configuration is hard-coded in the application's source, but the actions of creating dialogs is still done at run-time.
Quote:
...is it a matter of hacking source code?
Yes, but going down this path means you are taking on additional responsibility in one of three ways:
  • You will have to track your custom changes, & apply them to updated applications as they become available.
  • You get to determine if your fixes continue to work in new versions of the application. As code bases evolve, your hacks may no longer work. You may end up continually chasing & monitoring the eccentricities of whatever projects are maintaining & enhancing the applications you use.
  • Change the existing code once, but never update anything again. Ever.
All of these solutions have their shortcomings.

I'd suggest simply getting a bigger external monitor.
Quote:
We are talking open source stuff here...
While Open Source implies access to source code, this doesn't mean a great deal unless one has the skill set & knowledge to modify it, or is willing to pay someone else to do the same work. Secondly, someone needs the time to learn the code base. Most projects aren't written in ten lines of code. Most are of the order of tens to hundreds of thousands of lines if not more. Learning a substantial code base is not a trivial task or something that can be done in a weekend. A more prudent guess is to allocate months.
Reply With Quote
  #6   (View Single Post)  
Old 13th October 2012
xmorg xmorg is offline
Real Name: Tim Cooper
Fdisk Soldier
 
Join Date: Sep 2010
Location: San Diego
Posts: 56
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by ocicat View Post
For compiled applications, resources can either be configured at compile-time or dynamically at run-time. The advantage of compile-time configuration is an obvious performance gain, whereas run-time configuration has to be parsed during execution. For the dynamic languages, most of this kind of configuration is hard-coded in the application's source, but the actions of creating dialogs is still done at run-time.

Yes, but going down this path means you are taking on additional responsibility in one of three ways:
  • You will have to track your custom changes, & apply them to updated applications as they become available.
  • You get to determine if your fixes continue to work in new versions of the application. As code bases evolve, your hacks may no longer work. You may end up continually chasing & monitoring the eccentricities of whatever projects are maintaining & enhancing the applications you use.
  • Change the existing code once, but never update anything again. Ever.
All of these solutions have their shortcomings.

I'd suggest simply getting a bigger external monitor.

While Open Source implies access to source code, this doesn't mean a great deal unless one has the skill set & knowledge to modify it, or is willing to pay someone else to do the same work. Secondly, someone needs the time to learn the code base. Most projects aren't written in ten lines of code. Most are of the order of tens to hundreds of thousands of lines if not more. Learning a substantial code base is not a trivial task or something that can be done in a weekend. A more prudent guess is to allocate months.
Aye /agree. One of the reasons I went to freebsd was that linux distros vary wildly in configuration and change a LOT over time. The version im on doesnt even have a xorg.conf, or any of the /xresources/xdefaults files that are called for in forcing geometry.

My main comp monitor is a bigscreen tv and I dont notice oversized dialogs but what about netbooks/laptops? not being able to see teh "print dialog" on a laptop because it takes up WAY too much space vertically is really annoying hehe.

I think it would be really nice to set the GTK "print" dialog to resizable somehow, there has gotta be a flag somewhere...
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Chromium loses focus in text boxes kly FreeBSD Ports and Packages 4 19th October 2011 02:53 PM
move install to new server larger hard drive (raid system) carpman FreeBSD General 16 24th November 2009 10:57 AM
Annoying blue config dialog _hmp_ FreeBSD Ports and Packages 11 28th December 2008 05:37 PM
Opera Font and Dialog Color Problem roddierod FreeBSD General 4 26th September 2008 02:39 PM
How to look for open slots in Sun Boxes revzalot Solaris 1 19th July 2008 04:54 PM


All times are GMT. The time now is 07:56 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick