On Sun, 2013-08-11 at 13:54 +0200, Kjell Ahlstedt wrote:
>
> You seem convinced that the shorter a program is, the easier it is to
> understand it. I'm not so sure.
>
> I get the impression that you don't understand how a GUI system works,
> Much work is going on behind the scene.
> An example: When you call m_TextView.get_buffer()->set_text("Hello
> world!"), the text is stored somewhere, the TextView is invalidated
> (marked that it shall be redrawn), but the text is not written to the
> screen. That's done later, after your function has returned.
> If your window is later hidden because another window is moved on top
> of it, and your window is then still later made visible again, the
> TextView is once again redrawn without your function being called. It
> your function contains a long calculation, taking minutes or hours,
> your window is not redrawn. The best way to avoid that is, like
> several people have mentioned, to create a separate thread of
> execution for the long calculation.
>
> You are trying to learn two interesting but rather difficult
> techniques, GUI programming and multi-threading, at the same time and
> mixed up. Well, GUI programming is not always difficult. It becomes
> more difficult when your application also needs multi-threading.
>
> I wish I could point out some good web sites for you to start with.
> I'm sure there are some, but I don't know where. There is of course
> the gtkmm tutorial,
> https://developer.gnome.org/gtkmm-tutorial/stable/, but it does not
> explain what's going on behind the scene in a GUI system. I once
> learnt that by reading "Programming Windows" by Charles Petzold. It's
> an excellent introduction to MS Windows programming in C, but it's not
> the book to read when you want to learn gtkmm.
>
> The description of glib's main event loop,
> https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html,
> is definitely not written for beginners.
>
> Since you dislike buttons, can't you remove all buttons and the button
> box from my example program? Remove all code that has anything to do
> with the buttons except
>
> // Start a new worker thread.
> m_WorkerThread = Glib::Threads::Thread::create(
> sigc::bind(sigc::mem_fun(m_Worker, &ExampleWorker::do_work),
> this));
>
> which you move to ExampleWindow's constructor. And you can change the
> loop in ExampleWorker::do_work() to make it run forever, if you like.
>
> Kjell
>
Thanks, Kjell.
I might not be as out of it as I appear. I totally am not convinced
that the shorter a program is, the easier it is to understand. A
program will often be much easier to understand if it had more
components in it build up.
An example of my understanding that it's more common to be the opposite
of what I'm specifically asking for in this thread, the second of the
examples are easier for a novice to understand.
// code example 1a begin
// ----------------------------------------------
str =+ "New text appended";
// ----------------------------------------------
// code example 1a end
// code example 1b begin
// ----------------------------------------------
str = str + "New text appended";
// ----------------------------------------------
// code example 1b end
I started to show two or three examples to let you know that I agree
with you on this. I asked for a minimum amount of program lines for the
operation to fill in a gap in my current understanding. When a person
is learning something new, there will often be gaps in his mind where he
might try to have an opportunity to ask the teacher or another student
how such a component fits. In this case, I ask to see a minimum amount
of lines that will display text to a window, and programmable be able to
do something else, then come back and update that display.
Also, I don't have a thing against buttons or any of the widgets. I
will eventually be using lots of widgets and lots of buttons. I'm kind
of trying to get grip of having a blank slate, then building upon it,
the widgets of my choice. There are lots of examples in the
documentations and sample lists that has many widgets included. At
present, when I remove the widgets to start with a blank slate so that I
can add the widgets of my choice the example gets broken. I'm having
problems starting out with a blank slate.
Most of the Helloworld widgets starts out with the "Hellow World" text
on a button. I did that immediately and have no problems with it. I
actually spent a lot of time trying to change that button to a textvew
widget, but couldn't get it done. When I started working with a
textview widget, I had problems, so I started out with a label widget.
I figured I'd come back to the text view when I could just output some
test, then append to it.
I finally got past that hurtle. Then I was trying to change my label
widget to a textview widget of which I could append to.
I'm able to do it with ease after all the word I have been doing in the
past few days, especially yesterday. I'll update an example of what I
was trying to do before the day is over. I'm trying to clean it up.
I appreciate all the tips from all the experts here. However, I can
tell from many of the comments that a lot of you are thinking I'm trying
to do something different that just learn how to work with a blank
window and add text to it.
I love the buttons, and all the various widgets. However, I couldn't
figure out how to put my own button where I wanted it because once I
interfere with the button that came with the widget, the program was
broke because it appeared to be designed not to work unless it started
out with a button.
I'm in a dilemma when I have a question very specific where, if the
question was specifically addressed, it would clear up a host of other
gaps in my understanding. But most of the answers are not dealing with
the actual question, which I believe might be very clear by the title of
the thread. Even now you have suggested that you might think that I
feel by there being less program lines, the program would be easier to
understand. But I was hoping for less lines so that I'd possibly have
more of a blank slate to build upon, and to see how it fit in the scope
of the many well organized examples in the documentation.
My dilemma is that if I try to clarify my question, I'm admonished for
being to verbose. If I don't explain, I'm presented with suggestions
that doesn't answer the question, and I'm still lost.
If I don't comment at all on some of the comments, I'm also admonished
for not commenting and pointing out how the example doesn't answer my
question.
So that best I can do is make a description, continue to research, and
be sure, since I have the best intentions, the group will eventually see
that my questions and discussion does have merit and I'll start to get
more support within the context of my actual question.
Thanks for everything, Kjell, especially for taking my last question
serious enough to consider adding a chapter to the well organized
documentation, and for taking the time to explain the problems with my
questions and current position, so that I can attempt to clarify the
parts you might misunderstand.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
