As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In the very near future my development setup will be upgraded and part of the deal will be dual monitors (yay!)
At least one of the monitors, possibly both, will be widescreen.
I've heard of developers using a second monitor, especially a widescreen monitor, in portrait mode. It allows for many more lines on the screen (albeit narrower) and runs a bit like having a long page of code.
Does anyone out there use this and think it's more effective?
I actually have 3 widescreen monitors in portrait mode and yes, it's a fantastic way to work. There's so much less scrolling around and you can fit all your debug / output / reference windows on screen at once.
The problem with using two monitors is that you'll generally be working on one main one and have output (or whatever on another). If you do have two, set it up so that your primary monitor is directly in front of you and the other (less frequently used) one is off to one side. I find that to be the best way to use a dual-monitor set up as it reduces RSI from being permanently twisted to look at a particular screen.
Additionally, there are some programs available to provide virtual screen splits which I've fund very useful for large/widescreen monitor setups.
[edit] ..and yes, you should write functions short enough to fit on a single page, but being able to see more functions at any one time can often make development easier in my experience :-)
[edit2] Running Visual-Studio-esque IDEs in portrait on a widescreen monitor is fantastic when it comes to debugging compile errors as you have more useable space to see code and errors at the same time. I suppose you could argue that if you compile regularly enough though, you shouldn't see that many errors at one time? ...but who codes like that? ;-)
Since you shouldn't write functions that are longer than a screen, making the screen much longer is a little bit of cheating, isn't it? ;)
Anyway, I found portrait mode not really better when coding, and only with my old 17" widescreen in portrait mode was viewing / editing documents better. With two large screens in landscape mode, You can put two pages on a screen when viewing documents, and have many tool windows open at both sides of the IDE's text editor. So no, portrait mode is not better, unless you have four of them to make up a really large screen (there was a photo of such a setup on a Microsoft blog, but I don't remember where).
There are some applications where portrait is still better, though, e.g. if you have to show a document in large resolution, or if you have some monitor (as in network monitor) running and want to see more lines at once.
I can't imagine how that would speed up productivity. In my opinion, it is always easier to scroll up/down than left/right.
It depends on which IDE you use, if any.
Microsoft Visual Studio likes to take up a lot of the width of the monitor with its “Toolbox” and “Solution Explorer”, so I find it works better on a landscape monitor. As it will not let you undock an editor window, you could not even drag a code editor to a second monitor that was in portrait mode.
Also consider how your customers are most likely to have their monitors set up. You may wish to write any UI code with the same setup, so you get a feel for what the application will be like to use.
Depends how big your monitor is. We have 1 28" monitor in landscape and 2 24" monitors in portrait which flank the big monitor.
Works great for pair-programming!
At work, I run my primary monitor (secondary is the laptop screen), in portrait mode. I really like it. I've become spoiled to seeing more code at once. I don't find that it encourages longer methods at all. Occasionally, I run across code that is a bit too wide since the IDE sidebars cramp it a bit, but I largely use Eclipse (Rational Application Developer, but Eclipse-based), so s quick double-click maximizes the code window, and it's very useful. Another double-click and I have my sidebars back.
I also find it a very useful orientation for my email.
I recommend it highly.
Portrait mode widescreen monitors work very nicely for edting code, thank you. However, some monitors have poor viewing angles on one dimension, which would usually be vertical but becomes horizontal in portrait mode. This can make the colours bad or unusable if everything isn't aligned correctly.
I have never given it a try but I would imagine it would work pretty well. I personally like to keep my lines fairly short, and wide screens tend to give me fewer lines of code, so I would give it a try.
It all comes down to personal preference however, what ever allows you to be the most productive and works best for you is the way to go.
For me it's not effective at all. I use IDEs, so in landscape mode I have sidebars to navigate code, navigate project etc.
It's not silly but a matter of opinion. A widescreen in portrait is very nice for writing code, code width has never really been an issue, and being able to see more line of code on the screen is always nice.
The other reason to put a widescreen in portrait is so it matches the height of your other monitor, for example a 30" widescreen next to a 22" widescreen in portrait have close to the same height.
It all comes down to your preference.
I just have one big monitor at my home office.
I tried it once. I didn't like it. I usually have an IDE and IDEs are perfect for widescreen. It's faster to jump around if you can see your function list on the right, file list on the left, etc.
Also, I try to keep my functions small so this usually isn't a problem (I have dual 24"). If your functions are reasonably small, and you have widescreen, you can show two files side by side which is often more useful. Some editors allow you to split the window and scroll to two different parts of the same file. This is also very useful is far better than having 100+ lines on the screen. With my settings, I have 60 lines per screen on an editor. If I split the editor, I can see 120. If I do it again on the other monitor, I can see 240. That's quite a bit of code and generally only useful for very different parts of it.
If you're working mostly with text (as most programmers or other technical folks do), or even documents, then portait mode is much more valuable. In fact, the general trend in displays is all the wrong direction: aspect ratios are squishing landscape displays to a mail slot to better fit the format of movies. Personally, I have never watched a movie on my computers (laptop or desktop), and I'm not about to start now - that's what I have a TV for!
In reality, vertical pixels are the most valuable asset in computing - do whatever you can to get more of them - you won't be sorry you spent the money! I won't even buy a laptop with less than 1024-1080 vertical pixels, since that's the minumum required to display a full page PDF at a readable resolution, and (much) more is better. (Since PDFs make up a large portion of today's online documentation/manuals, that's a very big concern.) You should only think about width after you've got enough vertical pixels.
What I really want is a 15.4" or 16" laptop with a portrait screen - these should still be wide enough to package a full-size keyboard into the base - a FlyBook-style pivot arm would be nice, but isn't required.
I found understanding the intent of related functions are easier when you print them first on paper than understanding them directly from screen, never fails, why? Because you can easily review many lines of code at one glance, no need for incessant scrolling.
The same thing with monitor oriented in portrait mode, you can easily understand the intent of multiple related functions, re-factored or otherwise. But don't let having portrait screen be an excuse to write a function with many lines.
Writing this on stackoverflow using portrait screen :-)
I can easily see many posts at one glance :-)
If you are working with print material, yes, as for source, why not full screen your IDE and close the task panes you do not need?
I find portrait is only useful to me if I'm working on a web site, being able to see the entire page at once helps.
I would say if the monitor is large enough you don't need portrait mode (24" and higher) for writing code.
If the monitor is smaller than that, then portrait mode is preferable.
Ideally what you would have is a single 30" (2560 x 1600) as widescreen to work on your code along with utilities comfortably open nearby and a second smaller monitor nearby to preview the results (I am speaking about web coding specifically here but it would probably apply to most other coding as well - a screen the size of your target audience's screens).
The 30" screens have really come down in price now so it's probably worth the jump up. A 24" screen does have the advantage of significantly larger text at default font sizes. The text on 30" monitors can get to be a bit of grind unless you move up to 14pt.
Good luck.
I have 2 19" monitors currently. One I keep in landscape and one I keep in portrait mode. I find that working on documentation or reading long web pages is easier on the portrait screen. I have used this setup for coding also and find that it does help, however it was a learned habit. lol
Related
I've been trying different tiling WM's to see which one best fits my needs. Every time I try a new one, it looks good but I find other things that don't quite work the way I like. My requirements have evolved as I go. Initially, I didn't want to get into Awesome because having to learn Lua is not on my wish list but maybe I should give it a try IF it can do what I want better than the other tiling WM's out there.
I'm going to as specific as I can about what I want. I am running a 3440x1440 monitor. I want to use as much vertical space as possible (meaning, a full width, persistent but mostly empty status bar is not an option, but I do like the notification area and a date/time).
I understand it may not do everything exactly the way I want, which is oke. If it does more or less most of what I want I can weigh my options between Awesome and other tiling WM's (actually, only i3 which is what I'm using now but I'm open to better suggestions). I would very much appreciate it if people don't just say no to something it can't do, but say "no, but it can do ...". In other words, feel free to suggest alternatives that might be helpful as well.
Divide the screen in 3 columns, initially 30/45/25, with the right column split horizontally; Fully adjustable and resizable as needed during my work session;
Persistent layout; when closing the last application in a tile, I don't want that tile to disappear and the remaining tiles to resize. Just show an empty space and leave all tiles as they are.
tabbed tiles, so I see which applications are running in a tile (similar to i3).
Resizable tiles with the keyboard into 1 direction; When making the middle column/tile wider, I want that into a specific direction into another tile and leave the other side alone.
Certain applications I want to always launch into a specific tile. For instance, terminals always go into the right-most column top/bottom, browser/spotify always into the middle, atom/IDE always into the left. Some applications should always be floating. Obviously I want to be able to send them to a different tile after launch.
I don't want a 100% width status bar. It will be mostly empty which is a waste of screen estate. Preferably, I'd like a statusbar part of a tile, for example in the right-most tile, resizing with it. Otherwise I'd like it to be fixed to 30% and allow tiles which are not beneath it to use the full height of the screen. My reason for a statusbar is mute; I actually only want a notification area and a date time permanently visible. I don't need a "start menu", dmenu or similar is perfect, which I believe it has integrated.
Many thanks in advance!
The general answer is "Awesome configuration is code and it can do whatever you want". But there is a catch. Can Awesome be configured like you describe? Yes, totally. There is at least 2 distributions coming close enough (mine[1] and worron[2]) (at least for the tiling workflow, not the look).
The "catch" is that the workflow you describe isn't really the "Awesome way". Awesome is usually used as an automatic tiler. You have layouts that describe a workflow (code, web, internet) and manage the clients according to their programming. Manual tile management is rarely necessary once you have proper layouts. That doesn't mean you can't, I did, but it might be worth thinking outside the box and see if you can automate your workflow a bit further.
Also, the default layout system isn't very modern and makes it hard to implement the features you requested. My layout system (see link below) can be used as a module or as a branch and supports all features described above. Awesome is extremely configurable and it's components can be replaced by modules.
https://github.com/awesomeWM/awesome/pull/644
The layout "serialization" documentation is here:
https://elv13.github.io/libraries/awful.layout.html#awful.layout.suit.dynamic.manual
It is similar to i3 but has more layouts and containers. As for the "leaving blank space" part, it is configured using the fill_strategy:
https://awesomewm.org/doc/api/classes/wibox.layout.ratio.html#wibox.layout.ratio.inner_fill_strategy
As a word of conclusion, I would note that what you ask is "work exactly like i3". If you want such thing, well, use i3. Awesome is a window manager framework. Its goal and purpose is to create a customized desktop shell / WM. If it's what you want, then go ahead and learn it, nothing else can come close to the possibility and the level of control you can get out of it. However it takes time and effort to get to the point where you have "your own perfect desktop". Our users perfect desktops:
https://github.com/awesomeWM/awesome/issues/1395
[1] https://gfycat.com/SmallTerribleAdamsstaghornedbeetle
[2] https://www.youtube.com/watch?v=-yNALqST1-Y
The WM your are looking for is herbstluftwm (hlwm). Its a manual tiling window manager. The tiles which you are talking about are called frames in hlwm. Each frame can contain multiple windows. A frame can also be empty. Only if you kill a frame the other frames will automatically resize. You can add new frames vertically and horizontally and resize them. Each frame can also have a different layout to organize the windows inside. The layout you are looking for is max. This will stack the windows inside a frame on each other. It doesn't show you tabs like i3 however. hlwm allows you to create rules to open certain applications always in certain frames and workspaces. hlwm doesn't have a statusbar buildin. I personally like to use tint2. It can be used as a replacement for your requirement to see running applications as tabs.
I am currently writing an iPhone app (my first one) and never used
Size Classes
Auto Layout
Stack Views
To set the views/images/labels etc. on the screen. didn't use storyboard as well,
Every thing that is shown is coded.
I didn't start using these tools because back at the time (a couple of months ago) they seemed to be more of a pain than a true gain for my development process,
But looking back i feel i made a mistake and now I'm way too deep in code to start it all over again with the traditional/designated tools.
So, Having said that, are there any known frameworks and/or best practices to make sure that all that's printed are scaled exactly the same and have relevant ratio for each device size?
Something like: calculating the height/width ratio and somehow applying it to all the views/images etc?
is there any good way to get out of this mess?
A few days ago a client asked me if the transition to the iPhone 4s retina display was a difficult one, development-wise.
This made me ask myself whether I should have considered iPhones with high resolution dispays even before the iPhone 4 had been announced - creating artwork with higher resolution, preparing codepaths... (while, of course, creating high resolution artwork is never a bad idea, considering its use for marketing, porting to other platforms etc.)
Now, with the iPad being around for some months, first rumors of a future iPad with retina display emerge from the depths of the www. And I start wondering - would it make sense to prepare new projects for such an iPad? I'm pretty sure that apple will in fact release a retina iPad at some point in the future, because it would be quite a logical step. So, I guess the important question is "how soon can we expect such a device?". There is much to consider when thinking about that, most of all production difficulties and the impact of a resolution of 2048 x 1536 (if apple sticks to simply doubling the "old" specs) on a mobile devices performance...
So, what do you think? Will it pay up to prepare new projects for a retina iPad, starting now? Or do you think the overhead is not worth it, yet?
Maybe some of you are already developing with the retina iPad in mind..?
I'd be glad to hear some of your thoughts! Thanks alot, guys!
Edit:
Well, Apple just answered my question. Yes, it was in fact reasonable to consider a Retina iPad..!
I wouldn't spend too much time making your app work on a theoretical device. But that doesn't mean you can't be prepared. Ever since they started changing things around I've been considering the following:
Use vector art wherever practical. That way resizing should be simple
Don't assume that the screen is 768x1024 or 320x480. Try to make your views gracefully resize
Don't assume that there will be an on-screen keyboard
So far Apple have allowed time between announcing products and making them available, and even there un-optimised apps have still worked.
Most of my work is for a client who has their own designer, who provides me with layered Photoshop files to pick image elements out of. I now have a policy with them that ALL images will be provided to me at double resolution. I don't care if it's just text, if it's only going to be on the iPad, I want it at 2x no matter what.
That takes a lot of thinking and judgement out of the hands of the designer (who's a good designer but not a particularly good technician or strategist), and allows me maximum flexibility in what I'm building.
Right now, I don't think I'd build #2x support into an iPad app just now (although presumably 4.2 will allow you to do it and have it downgrade nicely, just like 4.1 does), but I have the graphics here ready to install when needed.
A few of Apple's apps (such as iBooks) have already been seen in the wild with #2x iPad graphical elements (mistakingly?) left in, so it is clear that a retina iPad is coming as soon as it is practical for Apple to affordably include such an incredibly hires panel.
It might be later this year, it might be a year from now, or it might be two years from now.
It doesn't hurt at all to prepare now though. It is easy to downres graphics, but it is often impossible to upres graphical elements without redoing them from scratch.
So short answer - do everything in #2x resolution now, but wait to include it with your app until the time is right. When Apple issues the call for retina iPad apps, you'll be ready to go and able to be featured on day #1.
I'm going to agree with the others. I'll go out on a limb and say I think it is highly likely that a Retina iPad will have 2x horizontal and vertical resolution compared to the current iPad screen, just like the did with the iPhone, because it is such a freaking clever idea in terms of the relative ease of support of the new resolution for developers, the backwards compatibility with apps that have not been updated, and it also gives Apple a mechanism for preventing developers from making a I'll-cram-in-more-UI-on-the-high-resolution-version interface...
So absolutely, planning ahead for this is a good idea. That said, the ideal would be to plan for full resolution independence where possible, using vector artwork and so on so you can re-export at new resolutions with minimum hassle.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm looking at getting a new LCD monitor, but I'm concerned that a glossy monitor might cause more eye strain after a long day of work. I typically spend a lot of time in front of my monitor, so eye strain is definitely something I have thought about. Do you prefer the matte or glossy LCD screens and why?
Matte, because you get fewer reflections on it, which is good if your workplace is bright. I've worked with both, but especially if you have bright objects around your monitor, or windows at the side, you'll really want to have a matte one.
Constantly having reflections in it is really annoying, and hurts the readability in the long run.
I have a glossy screen on my laptop and I have an LCD standalone monitor that I hook up. I like them both for different reasons.
Reasons I like my glossy monitor:
Graphics look great
Colors look vivid
Presentations look awesome
Graphics are really easy on the eye and just seem to flow like on TV
Great for games which all look phenominal
It's widescreen, great for movies
I can see all my code without having to scroll right [because of the widescreen]
Reasons I like my Standalone Matte Monitor:
My code is easier to read [Consequently this is what I use for programming]
Graphics I design on my glossy screen don't always look great on my matte monitor, but graphics I design on my matte screen always look fantastic on both.
It's bigger (may not be relevant to you)
It has a higher contrast ratio and better backlight
If you're somewhere bright or have a light source behind you, i.e. you're sitting with your back to the sun, the glare can be intollerable on both screens... whichever has the highest "Bright" setting will win out here.
What I find a lot of people say about "You should use matte because..." or "You should use glossy because..." are just repeating what the guy in FutureShop or CompUSA spewed out trying to sell them what they ultimately bought.
I have one of each, I love having one of each and love them both for different reasons. Pick the one that's best at whatever you're going to be using it for.
My suggestion is this: Find somewhere you can try them both out side by side for what you're going to be using it for, or if you can, try each of them out for a few days to decide.
I prefer glossy, as long as the light isn't shining on it. Check where your computer is, and where your lights are and where your windows/skylights are. Otherwise, I would always use matte.
I think this is pretty much a personal choice. I used to think that glossy is unbearable until I got a laptop with a glossy screen and was forced to work with it for some time. Now I don't even care too much and don't feel that it's much worse. If I had a choice, I'd still choose a matte one, however.
I went through the same dilemma when I bought my current laptop. I'm an old timer and I didn't want the glossy screen. I almost bought a different one because I wanted the matte screen. I would go into Circuit City and Best Buy and I would hate the glare. I then used one at a friends house for a few hours in more real world conditions and I liked it. I bought a glossy one but I was still torn about my decision.
Now I'm glad I got the glossy and I wouldn't buy a laptop without one. Not only does most things look better on it, but it has a great viewing angle. I tend to use my laptop a lot when demoing stuff or working with a user. You can't beat the viewing angle of the glossy displays.
After two years of using it I rarely run into situations where I run into glare from bright lights. The few times I do, just a slight repositioning is all that is required to fix it.
When I replace my current monitors they will be glossy. The issues with a laptop, because it's mobile, just don't really exist with a desktop monitor. Neither of my two desktop environments present a glare issue. I currently have one glossy and one matte at work and I don't really see a difference between one and the other as far as eye strain. For me it's all viewing angle and how great stuff looks on the glossy one.
I think glossy gets too much stick. The reflections can be a nuisance in the wrong environment, but matte screens don't give the pure, unmolested picture that some people seem to think - incoming light gets diffused over the screen's surface by the anti-reflective coating hence the sharpness and contrast that the underlying panel is able to offer are degraded somewhat.
I use a non-default Windows colour scheme on most of my machines, and have a laptop with a 124 DPI screen, which Windows is set to.
A lot of programs I tested or even use daily seem to have problems with that, showing for example non-standard sizes of controls, cut-off UI elements, unreadable text and so on. There is the whole range from slightly annoying to (nearly) unusable.
Now I feel that a lot of these issues are unnecessary. A simple test run on a high-resolution screen in a few colour schemes would show them, some of them are even very easy to correct (like always using clWindow, clWindowText and clBtnFace instead of clWhite, clBlack and clSilver). Some of them are harder, like proper control sizing.
So my question is: Do you try to follow the recommendations in the UI guidelines regarding system colours, sizing and spacing of UI elements, and font sizes and faces? Is testing for compliance to them part of your QA process? Do you even try to lay out your forms in dialog units instead of pixels, even though most of the IDEs (Delphi in my case) have pixel-oriented designers?
[EDIT]: On re-reading this after sleeping I notice that this question may look like an invitation for fruitless discussion. It is not meant that way, I'd definitely be interested in tools to help me create applications that conform to the UI interface guidelines, an area where I feel Delphi is letting me down a little. See also my own answer.
I definitely don't. It costs time that I prefer spending on improving the experience of many rather than the few who use non-standard windows settings. A few things I usually do, which should still fix some of these issues:
use clWindows etc. because that's the standard for Delphi controls anyway, so why change it?
place labels above entry fields rather than to the left, which should solve many size problems
make sure the forms resize properly, by setting the anchors
make sure the tab order is correct (which can become a major annoyance if not done)
But I certainly don't take the time to set up test computers with odd resolutions and colors, or even worse, change my development box to use them (which will screw lots of things that again take time to reset properly).
If a paying customer reports problems with non-standard settings, it depends on the customer whether they will be addressed. If he orders 100 licenses, his chances are good. If he uses these settings because he is visually impaired, his chances are good. If he makes it part of the requirement, I will do it, but charge for the additional work.
Today, so much software doesn't work properly at a non-standard DPI that I don't think it's worth trying to fix it. The trouble-shooting FAQs for many applications just instruct users to switch to a normal font size for related problems. Microsoft acknowledged lack of proper DPI support in 3rd-party software and redesigned the display scaling methods in Windows Vista, where all GDI operations are scaled on a low level instead of relying on applications being aware of the DPI setting.
Final answer: it depends on your software's audience. If your software is likely to be used by disabled users, it might be worth the effort.
Apart from using the proper colour constants for standard colours I invest some extra effort for applications that we need to use internally on high DPI screens, or where customers may need this.
I have a unit with helper functions for determining proper sizes and placement margins, which compute these from the default GUI font and the standard values in dialog units as given in the UI guidelines, and with helper functions to compute the maximum width / height of an array of controls, place controls, things like that. For fixed size forms and dialogs I calculate the placement of controls once after translating their text with GNU gettext, for resizable forms I do this in an OnResize handler.
This gives good results, is however time-consuming. I would like to have something like the wxWidgets sizer functionality, which automates resizing once the minimum size of a control is set. I have never seen something similar for Delphi, though.
I occasionally test it myself for large fonts, because my Vista laptop is set to Large Fonts. Colors, not so much, but I rarely specify colors on controls.
However, proper resizing is pretty hard. I usually set Forms scale to false, so as that they won't resize wrong.
There are a few tools for auto-resizing forms. I did look into them, but never got around to testing them properly:
TFormResizer
ElasticForm - ironically (given the component's area) most of the text in this page won't show up in Chrome...
JVAutoFormSize (in JVCL - doesn't seem to be very useful from what I read)