Tag Info

Hot answers tagged

66

There are literally half a dozen of toolkits that could be considered “native” on some system. Some of these have rather unique concepts or capabilities, and replicating them in a cross-platform toolkit is tedious. The look & feel of an application is not only determined by a “skin”, but also on the layout and how it behaves. Some considerations: In a ...


53

Isn't it only a matter of designing buttons that look like 'native' buttons? Well - sort of, for buttons. But this might be harder than you imagine. These days the graphics used to represent GUI components aren't as simple as random bitmaps that are stretched (since these don't scale very well at all) - they're often vector based graphics with a lot of ...


37

I'd say yes, it is. There's sort of a pendulum effect in program development. First everything ran directly on the computer. Then when the computer became powerful enough to run multiple programs, they got mainframes with dumb terminals. But dumb terminals really suck in terms of usability, so as soon as computers got powerful enough to put reasonable ...


29

The thing to remember about GUI code is that it is event-driven, and event-driven code is always going to have the appearance of a mass of randomly organized event handlers. Where it gets really messy is when you try to shoehorn non-event-driven code into the class. Sure, it has the appearance of providing support for the event handlers and you can keep your ...


27

Building fast GUI prototypes is a good idea, and I have heard it being used in many projects. Early feedback is valuable indeed. However, it has its dangers: it is very tempting (for managers / users) to use the prototype code further and build the final application on it, which can have very bad long term consequences (this actually happened in one of the ...


25

I am generalizing over a couple of GUI libraries but on a very high level the most important concept that you need to understand is that a GUI is event driven. In a console application your user input usually happens at certain points that you defined. You prompt your user, you wait for his input, you calculate something based on that input. One of the ...


25

It sounds to me like you've got a requirement to fix something, but every time you propose a solution (and there are plenty of good ideas in your list) it gets shot down. This is the point where you need to push back. You don't need a vague idea that "this is wrong; fix it." What you need is a spec. Ask the people who want it fixed exactly what they do ...


25

This is easy, if they leave everything blank you prompt that this will print everything, however, the DEFAULT selection in that prompt MUST be to cancel. If they enter values, print whatever they asked for. This way, they won't accidentally blaze through the form and print everything. They'll blaze through and print nothing. They would need to pause, and ...


25

Why? Because they are solving a problem that doesn't exist. The only advantages over a downloaded IDE that I can think of is they occupy less disk space. However, as the price of disk space has dropped to $1/10 Gb, I don't see that as an issue. For those who regularly write code, the disadvantages of Web-based IDEs are that they are slower and less capable ...


23

There are plenty of web based IDEs. Some of them place an emphasis on collaborative coding. I think that whatever makes you think there aren't a lot of "good" web-based IDE's is probably the subjective definition of what "good" actually means. What features are missing etc... http://codiad.com/ http://www.eclipse.org/orion/ http://shiftedit.net/ ...


20

I think I see your point, but I suspect that there is also an opposite issue to consider. Essentially, I believe you are suggesting that, because the UI is the element of the application 'in the face' of the end users, the UI developers enjoy a higher visibility than the team members working in deeper layers of the app. Certainly I agree that there may be ...


19

I think many of the problems you are experiencing can be traced back to a simple cause. Most developers do not treat GUI code like 'real' code. I have no evidence or statistics here, just my gut feeling. Maybe they think it is 'just presentation' and not important. 'There is no business logic there', they say, 'why unit test it'? They laugh when you ...


18

The biggest difference is the design of the UI. A good GUI can make or break an application. Mac fans would draw attention to the beautifully designed GUI's of the average Mac OS X app and they've got a point, but this isn't a technology issue - it's a design/ethos/usability issue. As for technical issues, in no particular order: The user can do anything ...


16

For me it would be getting used to event-driven programming. It can still apply to console-based software but I find its mostly used with GUI. Once you grasp it, its a very powerful tool.


16

Product Managers are developer marketing folks. They perform an important role, but the number of them assigned to a product is more indicative of marketing workload, not development workload. I worked with some of the Product Managers when putting together the WPF futures post. While we typically do not discuss numbers for any of the staff, WPF has plenty ...


16

I don't think it's at all crazy. It all depends on who your target audience is. If you write an app and expect an average user to use it, you are probably better off with a GUI. If your app is a for developers, especially those that are used to CLI. Or if your app is targeting a sys admin who sits at his workstation and SSH's into 30+ other machines on a ...


15

In my company, there are a few people specialized in this job. They are designers. And they know HTML. They can be a bridge between the designers and the front-end engineers; which they usually are. This way, we just have to integrate their HTML. This is a hard job. There's a reason sites like "PSD to HTML in 24h" work well. The solution in our company is ...


13

Yes I use VIM because it's beautiful. Aesthetics mean a lot. If the UI is cluttered and ugly it will impact how you use the tool. NetBeans might do everything, but it looks awful and runs slow. I don't see many people using it.


13

TortoiseHg for Mercurial and TortoiseGit for Git are quite ready for serious use, in my experience. Don't know about Eclipse, but NetBeans supports Mercurial straight out of the box, and NbGit plugin gives Git support.


13

I think the biggest difference doesn't lie on the individual tasks but on two things: First and foremost, automation. CLI is inherently scriptable which is usually harder on Windows. I've heard things improved with PowerShell but I haven't used it. Second, the UNIX philosophy of "separation of concerns". I can write a small readline-based interface to ...


13

Yes, it does go deeper. Building a button which looks like a Windows or OS X button is easy, when you are building only this button. But the button must "behave" like the original ones, which might not be easy: maybe there is more space in one version available, but not in the other, maybe the color is more fitting for your design in the Windows version, ...


12

I suggest C#. It's very similar to Java in terms of syntax and the libraries available, and the Visual Studio Windows Forms designer is epic. It's also very easy to deploy on Linux and Mac if needed with Mono and C#.


12

It seems like your main question is how GUIs and CLIs can exist together at the same time, such as the Windows command console (cmd.exe). It's actually not as complicated as you might think. First, remember that even a GUI needs to be able to render text, so you can read filenames, labels on controls, or work with text inside of programs. It does this by ...


12

If there's one thing I could recommend, it'd definitely be Boost C++ Libraries. In fact, Boost is not a single library. It's a collection of them, and they're high-quality, portable, open source and well praised by people ranging from students to the C++ standards committee. Since Boost does not include GUI or anything else which is platform-dependent, ...


11

What does "dead" mean in a world where VB6 is still "supported" on Windows 7? WPF will be around as an option for a very long time (in programming years, anyway) and it's still being actively developed as far as I can tell. However, being pragmatic, we should be doing the "right" thing anyway, which is to maintain a separation of concerns, and reduce and ...


11

Even if you never intend to do desktop dev, I would suggest you get enough experience that you would have an informed opinion on when it is better to use a desktop solution over a web client.


11

It's only needed for people who do Java Desktop GUIs, and there's alternatives now. I spent a few years doing JavaEE apps and console-based apps. Never needed to touch Swing, and I was a successful JavaEE developer.


11

Like you say. In general, Hungarian notation is a bad practice. I like to keep my names as close to the domain as possible, but sometimes what you are trying to say is that this is the textbox and this is the label. See Kramii's answer to another question for his very reasonable take on why he still uses Hungarian in certain situations. As with all code, ...



Only top voted, non community-wiki answers of a minimum length are eligible