I want to start a Process Manager project in C and it's suppose to have a Graphical User Interface. It's my first GUI project and I have no idea about it. After some searches I found that I should use winapi32 libraries.
My question is:
Should I write my project like a Console-based one and then I add GUI to it or I should think about GUI at beginning of my project?
I would like to say that it's best to write the application as a command line application, then write a wrapper in GUI. This way you get the most flexible application with a total separation between the GUI and functionality.
But I won't say it! :-)
From my experience it's very difficult to totally seperate the GUI from the application, and thus you should built it with GUI in mind. Your code must open windows, report progress, react upon GUI events, so you must be well familiar with the GUI system you use.
But you must also maintain a separation between the GUI and the functionality as much as you can. For example, make your callbacks short, and direct the funcionality to non-GUI parts of the application. If you need to report progress during long calculation, pass a callback to the calculation algorithm instead of mixing GUI progress commands within the algorithm.
You also must bear in mind that most (if not all) GUI system can do GUI commands only within the main application thread, and build the program accodingly.
So in summary - yes, think about GUI at the beginning, it will be easier this way, but also keep a good separation between the GUI and the functionality,
Why changing the program during development? Just design it like it should be in the end.
You could design your program in a way that enables you to use both, text and graphical user interface. Offer an abstracted interface to the core functionality and use it from the text and the graphical interface.
If you want start top-down and not bottom-up you should choose whatever you prefer to start with a text or graphical interface that calls stub-versions of your interface.
Why write your project like a console-based one, since it's gonna end up with a GUI?
If there are any things you want to try it out first (like you don't know how to do a,b or c), sure you can implement that as a side project.
But as far as your main Project goes, that's what I'd do :
Carefully plan and design
What is it gonna do?
How are you gonna do it?
What should the User Interface contain in order to fully accomodate what you need
Coding
Test and Debug.
Repeat 2 & 3 until perfectly satisfied.
Hint :
A. I wouldn't suggest you to add your GUI to an existing console app, 'coz this will most likely lead to messy code and/or a messy UI.
;-)
B. Always study before trying to implement anything. You simply can't imagine how much your knowledge of what can be done
influences what you can do (and most likely what you'll end up doing).
If you want to make an user interface, you can use QTCreator or Visual Studio forms projects...
QT is an excellent way to make cross-platforms and cute interfaces... Visual Studio forms are usable only in windows platforms.
When you're working with any of these technologies you have to put "componentes" in a "window" a then code them...
Related
Recently I started to have a look at the GTK library in C, and wanted to create GUI application. In fact, I want to create an image application, but I don't know how to make my application looking exactly the same as my drawing, I've looked throught the gtk3-demo and also the widget factory but problems remains;
How to create GUI application, how do I know which container should I use, how do I know what kind of widget ? etc... So I have a picture of what I want to do, but I have absolutly no idea how. What is the process, what question should I ask myself in order to get my GUI application done ? Drawing of my application link
I would very much recommend you play with the Gtk3 GUI using python. You can interactively create windows, containers. Even later, it is much faster to develop the GUI in python, as many have already experienced.
Most of the Gtk3 C/C++ tutorials are available in Python too.
Glade is excellent in many cases - particularly if you want only standard behaviour of the widgets. If you even slightly wander from that straight path, things can get complicated quickly.
If it is really necessary, there are several ways to incorporate C/C++ functions into the Python GUI to make those critical apps go faster.
I'm starting to make my first C program in awhile using GTK+. I've learned C to some extent and I've worked with PyGTK, so I have a decent understanding of both. But, I've never created GUI program with C. Though it worked, my last GUI program was a bit of a mess because the program logic was all mixed in with the GUI stuff. I've read that it's best to write the GUI and program logic in a decoupled way so that if you switch GUI libraries, it'd be rather painless.
Is this right? Let's say I'm adding an item to a visual list. Do I have a function that adds the item to a logical list and run that in a function that looks at that list and then updates the gui?
For example,
void new_item_button_handler()
{
add_item_to_array() /* Code dealing with program logic*/
/*
* Code here to look at array and update visual list using GUI commands
*/
}
What's the general process for doing this?
Any advice would be appreciated!
EDIT:
Thanks for the advice regarding MVC. Could you perhaps explain that in the context of the example I gave? There's a lot of info on MVC out there, and I'm having a hard time trying to figure out how it applies to my code example here.
I think you're looking for the Model-View-Controller design pattern.
traditionally this is solved with an MVC pattern. however if you are not disciplined, you will see business logic creeping into your view layer.
design your package structure as best you can so that everything fits neatly into a model, view, and controller packages. make sure you have well define interfaces for sharing data between packages. make every effort to design the packages in a way that each individual package will be testable and mostly usable without depending on the other 2.
i would also encourage you to look at the IOC pattern. this will help when connecting all your packages together. it will also help during testing when you need to mock up some stub classes to test 1 package independently of the other 2. IOC is the "wiring" of your application, it lets you mix and match objects.
I'm planning to write my first program (it'll be in C#), and I need help with a decision. I know I'll want to use custom controls in the final version of the program (probably these), but someone advised me to use standard WinForm controls until the program is running right. They said once things are running right, then I could replace the UI with the custom controls I want. Is this the best way for me to do it? Or should I use the custom UI controls from the beginning?
About me:
-Never written a program
-Have some light Access/VBA experience and classroom C++ Logic and non-UI programming
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Thanks.
It depends on some factors:
The complexity: a simple custom-draw control can easily replace the standard winform control but generally custom controls add new features and tend to have differents methods and properties. In this case, switching to the custom control is not a simple task.
Your experience: Since you are pretty new to this, using a custom control can add another level of difficulty. Generally, these controls offers more options than the winform controls. So, it would be wise to start with the simple winform controls.
Since this is your first project, I tend to agree with your friend. While there is nothing inherently wrong with starting with third party controls, you will find that there is much more documentation and help available for the built in controls. In your early development efforts, you will likely hit many stumbling blocks, regardless of the choices that you make. Therefore, starting out with the most well-travelled course may make things easier for you starting out.
Once you have a little more experience debugging some of the issues that you will inevitably experience while learning a GUI framework, then it would make more sense to start bringing in glitzy third party controls.
Just use the standard controls. Keep it simple, Keep it simple, keep it simple. Also know that if you are still programming next year (hopefully on other projects), you will look back at this code in shame -- but that is a good thing.
Never written a program? I would not advise using any third party libs at this point, you are still learning. If you want the benefit of custom controls, why not write them yourself? You get the custom behavior and you actually learn how this stuff works.
Also, this statement is a bit of a red flag:
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Design patterns are great, but until you get some experience it is hard to understand why they are so great. Start like everyone else writing 'bad' code and then come back to the design patterns. That way you will truly realize why they are so important (rather than just being told that they are). Don't try to grok the advanced stuff before being full competent with the fundamentals.
I want to write a standalone GUI based app for administering one of the most popular enterprise middleware products from a very big company. But that big company already has a admin tool and its free.
But guess what , its very very slow , since its written on the java/Eclipse platform.
I want to write a very fast responsive GUI tool natively for windows.
I do not have much experience programming for windows , So what library(open source preferably) i can use on windows to get the job done.
Note: I need to write it in C, Not C++ , But if i dont have any choice I guess i can do with C++.
So I basically need to write a GUI app in C with some good GUI library.
Please help me out.
Thanks.
Edit : I do not know OOP and don't prefer using it.
Edit : So my choice is down to Win32API and Qt.
my requirement is that of a simple GUI , nothing fancy. I will be using simple windows ,buttons and menus. But I may need to do some processing , which means GUI should not take up much resources.
Based on this I m thinking of using Win32 API , even if I have to take the pain to hopefully satisfy the users.
its very very slow , since its written
on the java/Eclipse platform.
Are you sure that this is the reason for the application's slowness? I am no
fan of Java, but before you reach any conclusion, have you made sure that
writing the software in c makes it noticably faster? It could be that the
application is slow for reasons that are not under the control of the GUI programmer,
such as a slow database or bad network latencies.
Also, I don't mean to be rude here, but do
I want to write a very fast responsive
GUI tool natively for windows.
and
I do not have much experience
programming for windows
not contradict each other?
If you want to write a C GUI app, stick to Win32 or GTK+.
Win32 is blazingly fast, and will let you access everything available to Windows. Take a look at this tutorial.
GTK+ is extremely easy to use, cross platform, and provides tons of extra functionality. Start by downloading the all-in-one bundle, and move onto a tutorial and the documentation.
Personally I'd recommend going straight to Python if you need quick, responsive GUIs, and just need to wrap some lower level stuff.
Why are you limiting yourself to C? Windows Forms and WPF and SIlverLight are all viable UI frameworks that are responsive and have tons of books. There's a reason you can't find much info about writing GUI apps in C - people don't do it.
For plain C, cross platform, native look, simple, scriptable UI, I suggest to have a look at IUP: http://www.tecgraf.puc-rio.br/iup/
If you really have to use C then you can use GTK+. Otherwise, I'd suggest a C++ library like QT or wxWidgets. However, that being said I still think it would be preferable to build a .NET (Windows Forms or WPF) solution. They should provide a better UI experience than Java/Swing.
If you really want to do it in C, you could use the Win32 API. But it's hell working with it. The Object Oriented variant isn't much better either, but it takes away a bit of the pain (MFC).
I strongly recommend you to use C++ with the Qt library, which is both cross-platform and open-source (LGPL). C++ Qt GUI applications are as fast as native Win32 applications, although they take more memory. And you can't even start comparing the productivity gains - Qt is a great library, terrifically designed for GUI programming with tons of other useful tools.
Most GUI toolkits are written in C++, so restricting yourself to C will limit your options somewhat. One option that is cross platform and written in C is GTK; it's originally for X, but runs on Windows as well.
edit: Of course, you could always just program directly against the Windows API (formerly know as Win32) itself. For simple GUIs, it's not too bad.
GUI components map very well into Object oriented paradigm. Using C for GUI applications is a bad idea, I've been there and it's much more confortable to do it in an propper OO fashion with C++. Of course you can sort of do OO with C but it's ugly to say the least.
In my opinion, more than the GUI frameworks you need to really work on the design of the application you building.
For a normal GUI in C/C++ Win32 provides enough of controls for a decent looking application with good response time.
What you should really focus on is how to make it multi-thread based upon the time your modules take for execution.
Consider this small example: You have a DataBase connection monitoring in your GUI which is probed every second. Another module may be sending some big files to other applications. Now if an application is single threaded, your GUI is bound to have response problem. If you database connection is very slow due to some network/db issue your app will hang irrespective of the GUI frameworks or hardware chosen, if it was a single threaded app.
But if you write a good design and dedicate a separate thread for GUI handling and other threads for handing background tasks, you will have a really good GUI response. That way you can perform other tasks in background and GUI gets updated when notification is obtained. Remember, it wont happen magically and you need to sync you threads and update GUI.
Also, avoid creating threads for each and every task. You need to check things which can take more time like sending big files or faster tasks like checking/reading if config file exists or not.
By using third party GUI frameworks you are increasing your dependencies in your application and you would require to ship additional dlls etc with you main application. With win32 things are pretty neat.
I'm looking for some arguments to pitch to my boss and fellow developers.
We're currently finishing up the preliminary UI mockups and getting ready to move on to the next phases of development. In the meantime, I've been digging through the depths of the Carbon, Win32, and wxWidgets APIs attempting to make some of the controls have a more native look and feel on the Mac and Windows platforms.
The more I dig into the Win32 and Carbon APIs to implement the things we want in our project's UI, the more antiquated they feel, and the more I'm beginning to think that we should be implementing the project as described in the last paragraph here.
We're using wxWidgets for our current projects. wxWidgets is coming along on the wxCocoa port, but it doesn't look like it's going to be ready for prime-time before we start major development efforts on our new application. On the Windows side of things, it wraps the Win32 API rather than WinForms or WPF (likely due to native vs. managed code).
We're already designing the system with the MVC pattern in mind, thus aside from having to write two native UIs, it should be very doable, and, IMHO, easier to get the desired UI effects using modern APIs such as Cocoa and WPF.
I've been trying to push these points subtly, but the start of major development is coming soon. Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
Thanks in advance.
Create your core code in Standard C++ and use Objective-C++ with Cocoa to create your user experience on the Mac and C++/CLI plus C# with WPF to create your user experience on Windows. Follow the platform guidelines for the Mac in your Mac version, for Windows in your Windows version, and don't even bother thinking about trying to share user interface code.
One good way to manage this is, instead of just Model-View-Controller, following a Model-Model Controller-View Controller-View architecture. Your Model Controllers are platform-independent and manage the higher-level functionality of your application. (For example, its entire concept of documents, file format, job queues, and so on.) Your View Controllers are platform-dependent and mediate between your Model Controllers and your user experience.
Of course you'll probably also want some platform-dependent code at the model level too; for example to use NSOperation on the Mac and thread pools on Windows to implement job queues. Just create your own lightweight abstractions for that sort of thing.
Actually I think using Qt has become very interesting since it's now LGPL
Every time you add a layer of abstraction, you trade control over the details for more rapid development. You'll be able to get a lot done up-front using some cross-platform framework. On the flip side, when you want to do something that the framework doesn't support—and lets face it: it isn't going to implement all possible things those native APIs can do—you either have to implement it (for all platforms) using the native API, or do some other wierd hackery to get a "good enough" solution. And of course, when things go terribly wrong, having that extra layer of code you don't own makes it harder to debug. There really is something to be said for owning your entire stack as much as possible.
Writing two font ends is a lot of work, maintaining two front ends is a huge amount of work, if you need your program to run on multiple platforms go with a multi-platform toolkit.
If you write platform specific front-ends, each using the state of the art tools for that particular platform, you will get a much better user experience - but the cost of developing and maintaining those will be on the same order of magnitude as developing the entire application from scratch for each platform (yes, even with MVC).
Personally, I'd rather stick multiplatform and don't give a damn for that eyecandy, but if I wanted to pitch the use of those native APIs, I'd work out the (end-user-visible) differences between how things are done in different GUIs. If you can convince them that, in order to feel native, the program's user interface has to look and feel very differently on Windows and OSX (because of different design guides/philosophies/whatever), they should understand that, even with wx, you would still have to implement it twice, to accommodate those different requirements, so you might just as well use the real thing, i.e. the native API.
Also see this thread on the Google Chrome mailing list discussing the same choice of UI for Chrome on different platforms.
Win32 is definitely waay to old, but you might want to look into something like Microsoft Foundation Classes which is designed to do native development with C++. I assume that a similar thing exist for MAC.
Personally if I was in your situation I would properly also go for QT or WX.
Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
No one likes a corridor-wiseass.
I think action speak louder than words...make a small prototype of how you think it could be done, and show it. Maybe you have to do this in your spare time.
Cocoa is really great so I think that with little code you can show an idea...well, this require that you know Cocoa enough.