Thread: [Dev-C++] Offtopic: Advice on GUI to learn

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

As a new programmer targeting the Windows environment, am I better off 
learning the WINAPI, wxWindows, or GTK?

Thanks,

Patrick

> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of P.T.
> Waugh MA
> Sent: Thursday, January 15, 2004 12:58 PM
> To: dev...@li...
> Subject: [Dev-C++] Offtopic: Advice on GUI to learn
>
>
> Hi,
>
> As a new programmer targeting the Windows environment, am I better off
> learning the WINAPI, wxWindows, or GTK?
>
> Thanks,
>
> Patrick
>
If you learn wxWindows you'll be able to compile programs for Windows,
Linux, and, I believe Macs from the same source code. Everything you need is
opensource and there are inexpensive tools to help, too.

Instead of limiting yourself to "Microsoft" Windows users, you'll be
expanding your potential to include Linux "Xwindows" users too. And,
possibly, helping to provide the public with OS choices. "We can't use Linux
(or Mac) because it doesn't run Patrick's "Spectacular Can't Run Our
Business Without It Software", Oh, I see it does" ;-D

Just my 1/2 cent worth; off my soap box now.

Ken Bradford
Alpha II Service, Inc.

>>As a new programmer targeting the Windows environment, am I better off
>>learning the WINAPI, wxWindows, or GTK?

looking forward into the future microsoft´s winapi is dead. Because
"Longhorn" has no winapi anymore. I don´t know what comes then
but you have to learn a new api. So I think wxwindows is very easy
to use, it´s a crossplattform toolkit and is´s very mature. In com-
bination with Dev-C++ you have a very powerfull environment under
windows and linux to develop cool apps. Not to forget: FOX-Toolkit!
Look here: www.fox-toolkit.org

Regards Olli

-- 
icq: 172670232
homepage: http://www.the-unchallenged.de
Aus aktuellem Anlaß: http://schmidt-soll-bleiben.de/

On Thu, 15 Jan 2004, Oliver Brandt wrote:

> looking forward into the future microsoft=B4s winapi is dead. Because
> "Longhorn" has no winapi anymore. I don=B4t know what comes then
> but you have to learn a new api. So I think wxwindows is very easy
> to use, it=B4s a crossplattform toolkit and is=B4s very mature.

Well, the Win32API is depricated. But it will be around for awhile yet.
Microsoft can't just get rid of it with Longhorn because that will break
Legacy apps.

But wxWindows is broken when the Win32 API goes away too, unless it is
completely rewritten on the Windows platform to use the WinFX API. All
wxWindows does is wrap native Win32 API functions in classes and such.

> But wxWindows is broken when the Win32 API goes away too, unless it is
> completely rewritten on the Windows platform to use the WinFX API. All

What is WinFX?

Mohammed 

WinFX is the new managed API that will replace the Win32 API in Longhorn.
Basically, the current incarnation of .NET is a subset of the WinFX API.
So if you have seen .NET code, and how it creates windows and such, you
have seen what the WinFX API is going to look like.

Mike

On Thu, 15 Jan 2004, Mohammed Iqbal wrote:

> > But wxWindows is broken when the Win32 API goes away too, unless it is
> > completely rewritten on the Windows platform to use the WinFX API. All
>
>
> What is WinFX?
>
>
> Mohammed
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

No one here has mentioned FLTK.
How would you compare FLTK to wxWindows or FOX?
What would be the biggest advantage / disadvantage over the other tool 
kits discussed in this thread? excluding WIN32.

As a general rule, it is best to write code that is as portable as 
possible. I myself try to use the C++ STDs as much as I can. However,  
since what I do is to develop applications for UNIX machines and now 
MSW, speed in this case can be viewed as a challenge, but as I always 
say, "Either the user waits three nanoseconds or we spent $30K on 
restructuring the app."; we all know what the answer is to that one.
As I am trying to implement a better GUI to up coming applications, I 
have been doing some research and have found that the FLTK mailing list 
team is very dynamic as well as the FOX team. There is a lack of 
documentation for both libraries, but as someone said, "you can always 
have a look at the code".

What I am looking for in a GUI tool kit are three things. One, 
portability. As I said before I want the freedom to compile here, there 
and any where. Good bye MFC!! and other MSW-only gui tool kits
Second, it must be a FSF tool kit. I want provide the quality of service 
and professionalism the customers are used to, with out the problem of 
having to by licenses for this machine or that one or another; savings 
in this area will substantially lower the price of the app. development; 
making me more competitive / marketable. Good bye Qt!!
Third, but not least, it must be a C++ tool kit... mmm ... or have C++ 
bindings like gtk+ [gtkmm]

Stability, learning curve and other aspects that are to be considered 
will be looked at when and only when the above conditions are met.

I would like to thank you in advance for you help, and any other member 
of the Dev-Cpp mailing list that might be interested in pitching in the.

PD
Are there any programers in this list that live in the Toronto are? S/He 
must be fluent in C++ and Dev-Cpp.

mu...@cb... wrote:

>On Thu, 15 Jan 2004, Oliver Brandt wrote:
>
>  
>
>>looking forward into the future microsoft´s winapi is dead. Because
>>"Longhorn" has no winapi anymore. I don´t know what comes then
>>but you have to learn a new api. So I think wxwindows is very easy
>>to use, it´s a crossplattform toolkit and is´s very mature.
>>    
>>
>
>Well, the Win32API is depricated. But it will be around for awhile yet.
>Microsoft can't just get rid of it with Longhorn because that will break
>Legacy apps.
>
>But wxWindows is broken when the Win32 API goes away too, unless it is
>completely rewritten on the Windows platform to use the WinFX API. All
>wxWindows does is wrap native Win32 API functions in classes and such.
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>  
>

-- 

FYI
http://www.astro.umd.edu/~marshall/abbrev.html

E-Mail Policy
http://www.vif.com/users/escalante/Email_Policy.html

* You cannot exercise your power to a point of humiliation.
                               - Jean Chretien

* The media's the most powerful entity on earth. They have the 
  power to make the innocent guilty and to make the guilty 
  innocent, and that's power. 
                                - Malcom X
* "Innocent until proven guilty", no... not in Canada!!

My main gripe with FLTK. The widgets are uglier than just about anything I
have ever seen. The icons and such look like a child drew them. FLTK 2.0
is supposed to be skinnable so that problem will go away, but AFAIK, right
now, FLTK is not skinnable.

Other than that, it's a nice toolkit.

Mike

On Fri, 16 Jan 2004, Maya wrote:

> No one here has mentioned FLTK.
> How would you compare FLTK to wxWindows or FOX?
> What would be the biggest advantage / disadvantage over the other tool
> kits discussed in this thread? excluding WIN32.
>
> As a general rule, it is best to write code that is as portable as
> possible. I myself try to use the C++ STDs as much as I can. However,
> since what I do is to develop applications for UNIX machines and now
> MSW, speed in this case can be viewed as a challenge, but as I always
> say, "Either the user waits three nanoseconds or we spent $30K on
> restructuring the app."; we all know what the answer is to that one.
> As I am trying to implement a better GUI to up coming applications, I
> have been doing some research and have found that the FLTK mailing list
> team is very dynamic as well as the FOX team. There is a lack of
> documentation for both libraries, but as someone said, "you can always
> have a look at the code".
>
> What I am looking for in a GUI tool kit are three things. One,
> portability. As I said before I want the freedom to compile here, there
> and any where. Good bye MFC!! and other MSW-only gui tool kits
> Second, it must be a FSF tool kit. I want provide the quality of service
> and professionalism the customers are used to, with out the problem of
> having to by licenses for this machine or that one or another; savings
> in this area will substantially lower the price of the app. development;
> making me more competitive / marketable. Good bye Qt!!
> Third, but not least, it must be a C++ tool kit... mmm ... or have C++
> bindings like gtk+ [gtkmm]
>
> Stability, learning curve and other aspects that are to be considered
> will be looked at when and only when the above conditions are met.
>
> I would like to thank you in advance for you help, and any other member
> of the Dev-Cpp mailing list that might be interested in pitching in the.
>
> PD
> Are there any programers in this list that live in the Toronto are? S/He
> must be fluent in C++ and Dev-Cpp.
>
>
> mu...@cb... wrote:
>
> >On Thu, 15 Jan 2004, Oliver Brandt wrote:
> >
> >
> >
> >>looking forward into the future microsoft=B4s winapi is dead. Because
> >>"Longhorn" has no winapi anymore. I don=B4t know what comes then
> >>but you have to learn a new api. So I think wxwindows is very easy
> >>to use, it=B4s a crossplattform toolkit and is=B4s very mature.
> >>
> >>
> >
> >Well, the Win32API is depricated. But it will be around for awhile yet.
> >Microsoft can't just get rid of it with Longhorn because that will break
> >Legacy apps.
> >
> >But wxWindows is broken when the Win32 API goes away too, unless it is
> >completely rewritten on the Windows platform to use the WinFX API. All
> >wxWindows does is wrap native Win32 API functions in classes and such.
> >
> >
> >-------------------------------------------------------
> >The SF.Net email is sponsored by EclipseCon 2004
> >Premiere Conference on Open Tools Development and Integration
> >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >http://www.eclipsecon.org/osdn
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
>
> --
>
> FYI
> http://www.astro.umd.edu/~marshall/abbrev.html
>
> E-Mail Policy
> http://www.vif.com/users/escalante/Email_Policy.html
>
> * You cannot exercise your power to a point of humiliation.
>                                - Jean Chretien
>
> * The media's the most powerful entity on earth. They have the
>   power to make the innocent guilty and to make the guilty
>   innocent, and that's power.
>                                 - Malcom X
> * "Innocent until proven guilty", no... not in Canada!!
>
>
>

Dana petak 16. januar 2004. 18:02, Michael C Urban je napisao/la:
> My main gripe with FLTK. The widgets are uglier than just about anything I
> have ever seen. The icons and such look like a child drew them. FLTK 2.0
> is supposed to be skinnable so that problem will go away, but AFAIK, right
> now, FLTK is not skinnable.

Use eFLTK - fork of FLTK2 that is stable and have support for UTF8 and themes 
and many more...

Goran

Hi,

I would start with the wxWindows toolkit. It's cross platform, and easier
to learn than either the Win API or GTK. GTK also is somewhat buggy on
Win32 yet, and its widgets look rather out of place since it draws its own
widgets instead of using the native Win32 ones.

As far as the Win API, it's good to have some familarity with it, but most
people don't program with it directly anymore except for when the toolkit
can't do what they need. The main problem is that it is just too time
consuming. For example, it can literally take 100 lines of code using the
Win API to do what you can do in 10 lines of code with a toolkit like
wxWindows. Using the Win32 API directly is also more error prone.

wxWindows is probably your best bet. Easier to learn than GTK. Better
Windows support, and more cross-platform.

Mike

On Thu, 15 Jan 2004, P.T. Waugh MA wrote:

> Hi,
>
> As a new programmer targeting the Windows environment, am I better off
> learning the WINAPI, wxWindows, or GTK?
>
> Thanks,
>
> Patrick
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Michael C Urban wrote:
> Hi,
> 
> I would start with the wxWindows toolkit. It's cross platform, and easier
> to learn than either the Win API or GTK. GTK also is somewhat buggy on
> Win32 yet, and its widgets look rather out of place since it draws its own
> widgets instead of using the native Win32 ones.

GTK+ can look nearly native:
http://gtk-wimp.sourceforge.net/

> wxWindows is probably your best bet. Easier to learn than GTK. Better
> Windows support, and more cross-platform.

IMHO is GTK easier to learn than wxWin. But IMHO it makes much more 
sense to compare wxWindows to gtkmm and I think that gtkmm + glademm is 
really simple to use. glademm uses much modern C++ than wxWin

generally speaking, there isn't really good C++ GUI library, for each of 
them you can create list of disadvantages

Dana =C4=8Detvrtak 15. januar 2004. 21:25, Michal Molhanec je napisao/la:
> Michael C Urban wrote:
> > Hi,
> >
> > I would start with the wxWindows toolkit. It's cross platform, and easi=
er
> > to learn than either the Win API or GTK. GTK also is somewhat buggy on
> > Win32 yet, and its widgets look rather out of place since it draws its
> > own widgets instead of using the native Win32 ones.
>
> GTK+ can look nearly native:
> http://gtk-wimp.sourceforge.net/
>
> > wxWindows is probably your best bet. Easier to learn than GTK. Better
> > Windows support, and more cross-platform.
>
> IMHO is GTK easier to learn than wxWin. But IMHO it makes much more
> sense to compare wxWindows to gtkmm and I think that gtkmm + glademm is
> really simple to use. glademm uses much modern C++ than wxWin

Gtk is easier, and I suggest you to try GTKmm and glademm. It is very good =
GUI=20
toolkit and it is not buggy at all.

On the other hand, you can get a window in FLTK in 5 lines of code! It is v=
ery=20
fast, tiny and ... GUI toolkit, but it is not to be used with so called=20
"mainstream windows applications" as it donot support native windows look.=
=20
eFLTK on the other hand support some way of theming, so you can try to make=
=20
it more Windowish...

wxWin is big MFC like GUI library and I donot feel confortable when using i=
t.=20
I donot know why, I simply donot like that style.

Goran

On Thu, 15 Jan 2004, Goran [utf-8] Raki=C4^G wrote:

> Gtk is easier, and I suggest you to try GTKmm and glademm. It is very goo=
d GUI
> toolkit and it is not buggy at all.

If you use GTK though, be aware that most of its widgets are not thread
safe in MS Windows. (That's what I mean by buggy. They are thread safe in
Linux. But you can run into problems on Windows.)

Mike

Michael C Urban wrote:

>If you use GTK though, be aware that most of its widgets are not thread
>safe in MS Windows. (That's what I mean by buggy. They are thread safe in
>Linux. But you can run into problems on Windows.)
>  
>

Actually, you just can't update the GUI from other threads.

As Tor once said:

[quote from http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00227.html ]
I understand that in X11 the situation is different as the X server
naturally knows nothing about threads in the client, so as long as the
client (GTK+) itself knows what it is doing and uses appropriate
locking, there shouldn't be any problems in operating on the same
windows or other X11 objects from different threads (?).

But Windows knows the thread that created each window, and some
operations on a window from another thread might cause lots of fun
like deadlocks unless the application programmer is very careful with
what the window owning thread might be doing at the time another
thread tries to operate on the window.
[/quote]

Also, a quote from Tristan:

[quote from http://mail.gnome.org/archives/gtk-app-devel-list/2003-July/msg00015.html ]
you can still write a multi-threaded application with _ONE_THREAD_THAT_UPDATES_THE_GUI_.
[/quote]

You just have to use g_idle_add to make the updates run inside the main 
thread.

Daniel K. O.

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> Actually, you just can't update the GUI from other threads.

Yeah... That's what "not thread safe" means.

Mike

Michael C Urban wrote:

>On Fri, 16 Jan 2004, Daniel K. O. wrote:
>  
>
>>Actually, you just can't update the GUI from other threads.
>>    
>>
>Yeah... That's what "not thread safe" means.
>  
>

I don't see it as a big problem. There aren't too much cases when you 
really NEED to update the gui outside the main thread.
Say, if you're updating a progress bar for some task you're doing in a 
thread, eventually you'll get to 100%. Then, you usually want to do 
something else in your program. This is the moment you will need to 
synchronize with something else. If you're already doing the update 
inside the main thread, you'll probably won't need to lock other stufs.

I couldn't find more than a few specific real-world examples that would 
need threads to update the main GUI (but still can be written the other 
way to work with GTK+ on Windows), and wouln't need to synchronize with 
the rest of the program. Would be interesting if somebody show us some 
of these examples - and then forward it to the GTK+ developers.

Daniel K. O.

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> I don't see it as a big problem. There aren't too much cases when you
> really NEED to update the gui outside the main thread.

Updating the GUI in the main thread can cause noticable delays in the user
interface. The progress bar is a good example. If you update that from the
main thread, then every time the main thread has to repaint the progress
dialog, it's going to interrupt the user experience.

Animation and VR simulations that require rapid repainting of the display
are another area where you often don't want to tie up the main thread by
forcing it to handle the paint requests and such. The application can
become extremely unresponsive if the main thread has to handle such paint
intensive tasks.

Michael C Urban wrote:

>Updating the GUI in the main thread can cause noticable delays in the user
>interface. The progress bar is a good example. If you update that from the
>main thread, then every time the main thread has to repaint the progress
>dialog, it's going to interrupt the user experience.
>  
>

I don't think repainting the progress bar could take more time than 
painting a label... the idea isn't to make all the job in the main 
thread, just use a function that receives one arg, and call something like:

---
gboolean my_idle_callback_that_updates_the_progress_bar()
{
    gdk_threads_enter(); /* idle funcs run outside the lock */

    /* my_val is set in the other thread, inside 
gdk_threads_enter()/leave(),
    so the gui is not updated ouside the main thread, no problem at all.
     Now the idle func just have to retrieve the value, and use it properly.
 */
    float pb =  (float)g_object_get_data(G_OBJECT(my_progress_bar), 
"my_val");  

    gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(my_progress_bar), pb);

    if (pb>0.99) { /* are we finished? lets make the GUI sensitive again */
       gtk_widget_set_sensitive(toplevel_window, TRUE);

       /* here we could also change some texts, show a message window, 
play some sound, etc */
    }

    gdk_threads_leave();
    return FALSE; /* run this idle func just once */
}
---

The idle funcs have low priority by default, your thread could call 
gtk_idle_add a million times, and if the GUI is still busy with other 
things, the idle funcs will wait. Then they all will run; or you can 
just change their priority, calling gtk_idle_add_full, giving them more 
priority, for example, depeinding what you want. I don't think you can 
freely define this behavior in a log of GUI toolkits.

>Animation and VR simulations that require rapid repainting of the display
>are another area where you often don't want to tie up the main thread by
>forcing it to handle the paint requests and such. The application can
>become extremely unresponsive if the main thread has to handle such paint
>intensive tasks.
>

Yeah, this really seems a problem.
But GTK+ isn't intended for intensive repainting, like VR and 
Animations. You can use something like GtkGLExt, or GtkSDL, or something 
else, and plug this extra widget into your application. To manipulate 
their content you won't need to use Gtk+ API calls, you'll use 
SDL_BlitSurface, glVertex, etc. They should work fine when running from 
another thread.

Daniel K. O.

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> The idle funcs have low priority by default, your thread could call
> gtk_idle_add a million times, and if the GUI is still busy with other
> things, the idle funcs will wait.

True. This works. But its pretty old fashioned and not nearly as
responsive as doing the update in a seperate thread. Generally, this is
how we used to do things before Windows had preemptive multitasking.  But
now that we have preemptive multitasking, we don't like to use idle
methods anymore.

As an example, in Petzold's book, Programming Microsoft Windows (the Bible
on the Windows API), there is a program that draws random rectangles on
the screen as fast as the computer can draw them. The example uses the
PeekMessage function to only draw when the application is otherwise idle.
However, if you move the mouse cursor through the random rectangle frame,
it is noticably sluggish as the random rectangle loop runs between the
firing of mouse events.

Later in the book, the same program appears again, but this time using a
seperate thread to draw the rectangles. If you try both examples, I think
you find that the threaded version is more responsive than the version
that uses PeekMessage().

Then they all will run; or you can
> just change their priority, calling gtk_idle_add_full, giving them more
> priority, for example, depeinding what you want. I don't think you can
> freely define this behavior in a log of GUI toolkits.
>
>
> >Animation and VR simulations that require rapid repainting of the display
> >are another area where you often don't want to tie up the main thread by
> >forcing it to handle the paint requests and such. The application can
> >become extremely unresponsive if the main thread has to handle such paint
> >intensive tasks.
> >
>
> Yeah, this really seems a problem.
> But GTK+ isn't intended for intensive repainting, like VR and
> Animations. You can use something like GtkGLExt, or GtkSDL, or something
> else, and plug this extra widget into your application. To manipulate
> their content you won't need to use Gtk+ API calls, you'll use
> SDL_BlitSurface, glVertex, etc. They should work fine when running from
> another thread.
>
>
>
> Daniel K. O.
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

One other drawback to idle functions is that they cannot take advantage of
a second CPU like a thread can.

Thread: [Dev-C++] Offtopic: Advice on GUI to learn

Open Source C & C++ IDE for Windows

dev-cpp-users