Forum: Ruby Good GUI documentation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ruby S. (Guest)
on 2009-02-13 22:33
(Received via mailing list)
Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox
TK
QTK
Jruby with netbeans
shoes
wxruby
wide studio
rubyonsteel
monkeybars

I want something simple or at least well documented. Preferable drag and
drop. I would like to worry just about the ruby code and not necessarily
about the creation of the widgets.
Something close to what Visual Basic provides. I know this is wishful
thinking. I would purchase the book or even purchase the GUI software
(if it
is reasonable). But all the tools I mentioned have their limitations and
documentation is so so at best. I wish the tool to be cross-platform
with
native look and feel.

I know about the recent GUI survey, which I think was very nice. The
question is, what's next?
At any rate, I will appreciate some info about a well documented GUI for
Ruby.

Thank you all
Logan B. (Guest)
on 2009-02-13 23:07
(Received via mailing list)
On Feb 13, 2009, at 1:24 PM, Ruby S. wrote:

> shoes
> Something close to what Visual Basic provides. I know this is wishful
> At any rate, I will appreciate some info about a well documented GUI
> for
> Ruby.
>
> Thank you all
> --
> Ruby S.

We've done a lot to leave some good RDoc in place for Monkeybars, but
we do have very little in discussing how to bring it together, what do
real apps look like, etc. Recently we moved to Kenai and opened up a
wiki (http://kenai.com/projects/monkeybars/pages/Home). Our users have
been filling it with loads of documentation, which I think really
helps fill our documentation gap we have.

We're also really active on the mailing list and IRC.

Also, Monkeybars was designed with a GUI builder such as Netbeans in
mind. I don't write any code for making the layout for my production
apps in Monkeybars.

We don't have any Monkeybars books (yet), but we'd love to help you
get up to speed as quick as we can.
Mark R. (Guest)
on 2009-02-13 23:35
(Received via mailing list)
Ruby S. <removed_email_address@domain.invalid> wrote:
> Does anyone know of a good, well written book to learn one of the GUI
> supported by Ruby?

Though not a book, there is an extensive tutorial about using Tk with
Ruby that you can find at http://www.tkdocs.com

Mark
Joel VanderWerf (Guest)
on 2009-02-13 23:39
(Received via mailing list)
Ruby S. wrote:
> Hello all you happy GUIsher!
>
> Does anyone know of a good, well written book to learn one of the GUI
> supported by Ruby?
> I looked at:
>
> Fox

There's a good FXRuby book that came out recently:

http://www.pragprog.com/titles/fxruby/fxruby

It's lean, it's mean, what more could you want!
Alex F. (Guest)
on 2009-02-14 00:10
(Received via mailing list)
Ruby S. wrote:
> [Note:  parts of this message were removed to make it a legal post.]
>
> Hello all you happy GUIsher!
>
> Does anyone know of a good, well written book to learn one of the GUI
> supported by Ruby?

I believe the only Ruby-specific GUI books are for FxRuby (2008) and
Qt-Ruby (2005, documents previous version Qt3):

http://www.pragprog.com/titles/fxruby/fxruby
http://www.pragprog.com/titles/ctrubyqt/rapid-gui-...

> I want something simple or at least well documented.

Several have OK Ruby-specific API documentation (eg GNOME2, Wx, Fox),
but less of the kind of book-type material that guides you topic by
topic to understanding the toolkit's principles.

> Preferable drag and
> drop. I would like to worry just about the ruby code and not necessarily
> about the creation of the widgets.

Most of the toolkits offer one or more GUI builders to design layouts.
Typically, you visually design the layout then write your code in a
separate tool (eg an editor) and load the layout in Ruby and attach code
to handle the user interaction.

However, few offer close integration between the GUI design and the
code: XCode (for OS X/Cocoa development) comes closest, but is of course
not cross-platform.

> Something close to what Visual Basic provides. I know this is wishful
> thinking.

Yes, for now, at least for cross-platform development.

> I would purchase the book or even purchase the GUI software (if it
> is reasonable). But all the tools I mentioned have their limitations and
> documentation is so so at best. I wish the tool to be cross-platform with
> native look and feel.

> I know about the recent GUI survey, which I think was very nice. The
> question is, what's next?


Given that most of the cross-platform toolkits are developed by quite
small volunteer teams they progress, but not usually at a revolutionary
speed.

Like most people, you want all the good stuff from a toolkit: powerful,
simple, Ruby-ish, cross-platform, native, stable, with great tools and
better documentation. In the same way, many hope to meet that special
someone with an enchanting laugh, hot body, high IQ, beautiful eyes, fat
salary, and a tireless appetite for partying. Though in real life it
rarely comes in one package, one can still find something where it
clicks and works ...

I'd think over what you want to do with GUI programming in Ruby: do you
want to make a profitable application, or create and share an
open-source tool, or scratch an itch and have some fun? And consider
what you think you *most* need - eg, do you need to get your head round
general principles of GUI development, like "event-driven programming"
or "model-view separation", or use a RAD tool, or have the "best"
cross-platform appearance and behaviour.

Perhaps, using the survey and what else you know, choose two or three
toolkits that seem best fitted to your needs, then try to create the
same simple application using each of those. Then decide which you
enjoyed using the most (this is really important), and which had the
result most pleasing to you.

If you're more than casually interested in GUI, you're doing well to
invest a little time: the APIs are often large and so a GUI toolkit can
be long-term relationship. I've been doing Wx since 2004 and I still get
nice surprises (and a very occasional nasty one).

hth
alex
Michal S. (Guest)
on 2009-02-14 00:25
(Received via mailing list)
2009/2/13 Ruby S. <removed_email_address@domain.invalid>:
> shoes
> is reasonable). But all the tools I mentioned have their limitations and
> documentation is so so at best. I wish the tool to be cross-platform with
> native look and feel.
>

I have tried GTK recently .. and I was disappointed.

The wrapper for the library is pretty good AFAICT but it's still a C
widget library.

Many widgets are using an Adjustment for their data source (progress
bars, scroll bars, those range widgets, spinbuttons ..)

The Adjustment is sort of C range, and accepts only Floats as the
values. While it might be good enough for widgets with hidden values
and % progress bars it is not usable for widgets where you want to
show a value other than a simple number.

So to get date spinbutton, letter spinbutton, time range, etc. you
need to roll your own Range and your own widgets.

Actually the range widget seems to have some way of formatting the
text so you might get away with it for ranges that can be represented
as a float range and converted for display.

I guess this is unavoidable with C widgetry. Either the wrapper
implements flexible widgets that are incompatible with other languages
using the library or it uses the standard ones with limited C-friendly
functionality.


The other problem is with the GUI builder - Glade. While you can put
most (all?) simple widgets in place you can only create an outline for
a Treeview (this is how "list" and "table" is spelled in GTK). To put
together a working Treeview you have to do most of the work in your
code, the GUI builder cannot do that.

Still the GTK bindings are fine if you want something that works
reasonably in X and integrates well with the system. There is just
some mismatch between the language in which GTK is written and Ruby
unfortunately.

Thanks

Michal
jonty (Guest)
on 2009-02-14 01:21
(Received via mailing list)
Ruby S. wrote:
> shoes
> is reasonable). But all the tools I mentioned have their limitations and
> documentation is so so at best. I wish the tool to be cross-platform with
> native look and feel.
>
> I know about the recent GUI survey, which I think was very nice. The
> question is, what's next?
> At any rate, I will appreciate some info about a well documented GUI for
> Ruby.
>
> Thank you all
>

Although Shoes isn't drag and drop it is very easy to create simple ,
and not so simple, gui apps and
it is rather well documented on-line and via its integral manual, you
don't have to worry about widget creation - you just use them, look at
the examples to see what i mean

Although still work in progress it is fantastically cross platform and
has a good supportive mailing list

Have fun!
Phlip (Guest)
on 2009-02-14 01:31
(Received via mailing list)
>> I want something simple or at least well documented. Preferable drag
>> and
>> drop. I would like to worry just about the ruby code and not
>> necessarily
>> about the creation of the widgets.
>> Something close to what Visual Basic provides.

If you learned the "Shoes" platform, by Doctor Why, you would understand
how
Ruby makes coding easier than drag-and-drop to draw the widgets!
Phlip (Guest)
on 2009-02-14 01:35
(Received via mailing list)
Logan B. wrote:

> Also, Monkeybars was designed with a GUI builder such as Netbeans in
> mind. I don't write any code for making the layout for my production
> apps in Monkeybars.

I'm too lazy to search this up: Where's the best MonkeyBars screenshots?
Logan B. (Guest)
on 2009-02-14 02:13
(Received via mailing list)
On Feb 13, 2009, at 4:33 PM, Phlip wrote:

> Logan B. wrote:
>
>> Also, Monkeybars was designed with a GUI builder such as Netbeans
>> in  mind. I don't write any code for making the layout for my
>> production  apps in Monkeybars.
>
> I'm too lazy to search this up: Where's the best MonkeyBars
> screenshots?
>


David K. creates a Monkeybars app using Netbeans from scratch.
http://rubyconf2008.confreaks.com/monkeybars-easy-...

My blog has a few screenies in the posts:
http://www.logustus.com/2009/02/brushed-metal.html
http://www.logustus.com/2009/02/icons-using-rawr.html
http://www.logustus.com/2009/01/weekend-project-pa...

My company, Happy Camper Studios, makes its payroll with Monkeybars
apps.
This app is the 'alpha' app for Monkeybars. It inspired us to create it:
http://www.happycamperstudios.com/showcase/sat-int...

JotBot is a time tracking product that pops up and asks you what you
did on a regular interval:
http://www.happycamperstudios.com/showcase/jotbot/index.html

Twit and Twitter (I'm changing the name to Twittest) won first place
in the Java Script Bowl competition two years back.
http://www.happycamperstudios.com/showcase/twit-an...

Blowmage has a proof-of-concept/prank app I wrote for him at
Mountainwest, but his blog appears to have died. I'll see if I can get
a screen shot of it sometime.

Netbeans itself:
http://www.netbeans.org/features/java/swing.html
http://www.netbeans.org/images/v6/5/screenshots/ja...

I hope that helps!
James B. (Guest)
on 2009-02-14 06:45
(Received via mailing list)
>>
>

Useful resources here:

http://kenai.com/projects/monkeybars/pages/Resources

My article at IBM developerWorks (listed at the above link) is slightly
out of date (it refers to monkeybars 0.6.4, while the current version is
1.0.1), but I've passed along updated code so the example app should run
fine.


--
James B.

www.happycamperstudios.com   - Wicked Cool Coding
www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
7stud -. (Guest)
on 2009-02-14 06:55
Ruby S. wrote:
>
> I want something simple or at least well documented.
>

The language itself isn't well documented--or even adequately
documented.  The documentation is often non-existent or it's complete
shite.  The powers that be could get good documentation for free if they
wanted.  This is all they would have to do:

REXML#xpath


and then provide the means for users to post comments and within a year
the whole damn language would be completely documented by the users
themselves.  See the php docs for the best docs of any language I've
encountered.  Unfortunately, Ruby just shoots itself in the foot as far
as the docs go.  It doesn't matter how great a language is advertised to
be--if the docs suck, the language sucks.
Chad P. (Guest)
on 2009-02-14 09:45
(Received via mailing list)
On Sat, Feb 14, 2009 at 08:14:43AM +0900, jonty wrote:
>
> Although Shoes isn't drag and drop it is very easy to create simple ,
> and not so simple, gui apps and
> it is rather well documented on-line and via its integral manual, you
> don't have to worry about widget creation - you just use them, look at
> the examples to see what i mean
>
> Although still work in progress it is fantastically cross platform and
> has a good supportive mailing list

I have a question about Shoes, actually . . .

Where can I find a list of dependencies for it?  I seem to recall
reading
that it depended on some other Ruby libraries, but haven't been able to
find a comprehensive list.
Tom C. (Guest)
on 2009-02-14 10:26
(Received via mailing list)
7stud -- wrote:
>
> REXML#xpath
>
>
> and then provide the means for users to post comments and within a year
> the whole damn language would be completely documented by the users
> themselves.  See the php docs for the best docs of any language I've
> encountered.  Unfortunately, Ruby just shoots itself in the foot as far
> as the docs go.  It doesn't matter how great a language is advertised to
> be--if the docs suck, the language sucks.
>
Umm. Having a bad day, are we? Well I DO love good documentation, so I'm
with you on that, but there's another point of view I want to suggest:
Documentation simply records (hopefully in a well-organized way) what
someone knows or thinks YOU'll want to to know. That same information is
very accessible in a supportive community.

I'm a rank amateur in Ruby, with very limited time. I find it generally
quite enough to have the available documentation plus the community
knowledge in this discussion list. It's certainly more current than any
written documentation could be.

Not a perfect solution, but a pretty good one!

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< removed_email_address@domain.invalid >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zachary Brown (Guest)
on 2009-02-14 15:48
(Received via mailing list)
I've Shoes to build a couple applications lately. Some of the
documentation is pretty good but there's holes in it. It requires a
little experimentation to get the hang of it.

As a note, I was someone that really hated working with GUI code but
Shoes changed my mind on that :). _why has me sold.

-Zac
James G. (Guest)
on 2009-02-14 18:04
(Received via mailing list)
On Feb 13, 2009, at 10:54 PM, 7stud -- wrote:

> The language itself isn't well documented--or even adequately
> documented.  The documentation is often non-existent or it's complete
> shite.  The powers that be could get good documentation for free if
> they
> wanted.

They are pretty accepting of documentation patches.  I know because
I've submitted several.  Have you?

With the energy used in this rant you could have documented a standard
library instead.  I think that might help the community more.

James Edward G. II
David M. (Guest)
on 2009-02-14 18:36
(Received via mailing list)
7stud -- wrote:
>
I would turn that on its head. PHP has decent docs, I'll grant, but rdoc
isn't completely bad. And when something isn't documented, in Ruby, the
source is readable enough that I can usually find out what's going on --
in PHP, it might not be so easy.

Docs are nice, especially for newbies, but if the language sucks, the
language sucks, and no amount of documentation will save it. On the
other hand, if the language rocks, docs are a nice bonus, but a lot of
it should be self-documenting anyway.
Ruby S. (Guest)
on 2009-02-15 00:07
(Received via mailing list)
On Sat, Feb 14, 2009 at 11:34 AM, David M. 
<removed_email_address@domain.invalid>
wrote:

>>  Unfortunately, Ruby just shoots itself in the foot as far as the docs go.
> Docs are nice, especially for newbies, but if the language sucks, the
> language sucks, and no amount of documentation will save it. On the other
> hand, if the language rocks, docs are a nice bonus, but a lot of it should
> be self-documenting anyway.
>
>
Thanks to everyone for their comments and recommendations.I greatly
appreciate all suggestions and comments.
Michal S. (Guest)
on 2009-02-15 03:00
(Received via mailing list)
2009/2/14 James G. <removed_email_address@domain.invalid>:
> On Feb 13, 2009, at 10:54 PM, 7stud -- wrote:
>
>> The language itself isn't well documented--or even adequately
>> documented.  The documentation is often non-existent or it's complete
>> shite.  The powers that be could get good documentation for free if they
>> wanted.
>
> They are pretty accepting of documentation patches.  I know because I've
> submitted several.  Have you?

The point he is trying to make is that at the very place where the PHP
docs are published on the web users can post comments - which are
sometimes offtopic or misleading but often they are covering gaps in
the docs.

I think that if there is one thing PHP did right this would be it.

Still even with those docs, as somebody pointed out, PHP is a bad
language for me too so I avoid it as much as I can.

Thanks

Michal
Chad P. (Guest)
on 2009-02-15 04:05
(Received via mailing list)
On Sat, Feb 14, 2009 at 05:23:59PM +0900, Tom C. wrote:
> 7stud -- wrote:
> >
> >The language itself isn't well documented--or even adequately
> >documented.  The documentation is often non-existent or it's complete
> >shite.  The powers that be could get good documentation for free if they
> >wanted.  This is all they would have to do:
> >
> Umm. Having a bad day, are we?

I'm not sure why, but at least 50% of the 7stud posts I've read on this
list seem to be the sort of thing you'd expect from someone whose next
statement will be:

  . . . and I'm never using this language again!

I haven't figured out his/her motivations yet.
Chad P. (Guest)
on 2009-02-15 04:16
(Received via mailing list)
On Sun, Feb 15, 2009 at 01:34:42AM +0900, David M. wrote:
>
> I would turn that on its head. PHP has decent docs, I'll grant, but rdoc
> isn't completely bad. And when something isn't documented, in Ruby, the
> source is readable enough that I can usually find out what's going on --
> in PHP, it might not be so easy.

I have to agree with that.


>
> Docs are nice, especially for newbies, but if the language sucks, the
> language sucks, and no amount of documentation will save it. On the
> other hand, if the language rocks, docs are a nice bonus, but a lot of
> it should be self-documenting anyway.

While I disagree with a lot of what 7stud says, I do believe that good
documentation is rather more important than you make it sound.
Sometimes, I don't want to *have* to read the source in order to use the
library -- or, in some cases, the application.  That's especially true
when newbies come along, but also important at times for those who
aren't
so new to the language.

Self-documenting code is great for cutting down on the necessary amount
of in-code comments.  It should be viewed as a supplement to -- and not
a
replacement for -- out-of-code documentation, though.
jonty (Guest)
on 2009-02-15 15:57
(Received via mailing list)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Chad P. wrote:
<blockquote cite="mid:removed_email_address@domain.invalid"
 type="cite">
  <pre wrap="">On Sat, Feb 14, 2009 at 08:14:43AM +0900, jonty wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Although Shoes isn't drag and drop it is very easy to
create simple ,
and not so simple, gui apps and
it is rather well documented on-line and via its integral manual, you
don't have to worry about widget creation - you just use them, look at
the examples to see what i mean

Although still work in progress it is fantastically cross platform and
has a good supportive mailing list
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I have a question about Shoes, actually . . .

Where can I find a list of dependencies for it?  I seem to recall
reading
that it depended on some other Ruby libraries, but haven't been able to
find a comprehensive list.

  </pre>
</blockquote>
<br>
The main packages contain everything Shoes needs, but if compiling from
source there is advice on needed libraries in the readme<br>
<br>
<a href="http://shoooes.net/dist/shoes2.tar.gz">shoes source</a><br>
</body>
</html>
Logan B. (Guest)
on 2009-02-15 18:54
(Received via mailing list)
On Feb 14, 2009, at 12:43 AM, Chad P. wrote:

> On Sat, Feb 14, 2009 at 08:14:43AM +0900, jonty wrote:
> I have a question about Shoes, actually . . .
>
> Where can I find a list of dependencies for it?  I seem to recall
> reading
> that it depended on some other Ruby libraries, but haven't been able
> to
> find a comprehensive list.

Shoes is its own Ruby distribution. That's how you're able to
distribute a Shoes app without distributing Ruby.
Chad P. (Guest)
on 2009-02-16 06:10
(Received via mailing list)
On Mon, Feb 16, 2009 at 01:49:39AM +0900, Logan B. wrote:
> >find a comprehensive list.
>
> Shoes is its own Ruby distribution. That's how you're able to
> distribute a Shoes app without distributing Ruby.

Well . . . that's a surprise.  Thank you for the information.
Chad P. (Guest)
on 2009-02-16 06:12
(Received via mailing list)
On Sun, Feb 15, 2009 at 10:55:16PM +0900, jonty wrote:

[a bunch of HTML]

Thank you for the information.  I'd appreciate it if replies to me did
not come in HTML emails in the future, though.
David M. (Guest)
on 2009-02-16 12:22
(Received via mailing list)
Chad P. wrote:
> While I disagree with a lot of what 7stud says, I do believe that good
> documentation is rather more important than you make it sound.
> Sometimes, I don't want to *have* to read the source in order to use the
> library -- or, in some cases, the application.

That is very true, and good documentation is very important.

However, I stand by what I said. Unless the documentation is
comprehensive, including a thorough HACKING document for how to start
playing with the internals, there's always the chance with any library
that I might have to dig into it and find out what's going on. The
longer and more extensively I use a library, the more likely this is, no
matter how good the docs are.

So, while I would like to be able to get that library's equivalent of
"Hello World" working without having to read source, and while I do
appreciate a good README at least, I'd say from there on, the importance
of documentation vs clean code drops sharply.

As an example: Kernel#autoload is reasonably well documented. It claims
to use 'require' under the hood. However, when I click "view source" in
the rdoc, I get a pile of C which isn't really understandable, at least
to me. It's also not very monkey-patchable.

So while the docs were great to get it working:

autoload :Foo, 'lib/foo'

they were problematic when I wanted something more dynamic -- and
there's really no way to do:

autoload :Foo do
  require "some/#{interpolated}/value"
end

I even tried overriding Kernel#require, the way Rubygems does. And
autoload doesn't seem to use that custom require.

Contrast this to Rubinius. While I haven't tried this, it just took me
maybe five minutes on Github, without looking at any documentation, to
find where autoload is defined, and how it it works, and how to get the
effect I wanted (arbitrary code executed when the autoload is
triggered), probably even with the syntax I wanted -- all of which, if
there's a way to do in MRI, it probably requires intimate knowledge of C
and the MRI/YARV internals.

I think I found a grand total of two comments, each one line, maybe five
words.

Now, granted, the Ruby docs can probably be used for much of Rubinius,
to at least find out what it's supposed to do. But I should stress
again: MRI has good documentation via rdoc, but I just fell off a cliff
when it came to extending. Rubinius doesn't have documentation on its
website at the moment (though it is in the source tree), but I didn't
need the docs to figure it out.
Chad P. (Guest)
on 2009-02-17 00:40
(Received via mailing list)
On Mon, Feb 16, 2009 at 07:21:21PM +0900, David M. wrote:
> playing with the internals, there's always the chance with any library
> that I might have to dig into it and find out what's going on. The
> longer and more extensively I use a library, the more likely this is, no
> matter how good the docs are.
>
> So, while I would like to be able to get that library's equivalent of
> "Hello World" working without having to read source, and while I do
> appreciate a good README at least, I'd say from there on, the importance
> of documentation vs clean code drops sharply.

. . . but you first have to get to that point.  "Real" documentation's
primary value is for when you first encounter the library and need to
get
up to speed.  A lack of good documentation at that point might just
encourage you to use a different library, after abortive attempts to
figure things out quickly.  It has had that effect on me at times, at
least.

Anyway, I don't see why a library's API can't be fully documented.  If
its API *is* fully documented, any behavior that requires one to read
the
source is basically a bug.


> they were problematic when I wanted something more dynamic -- and
> there's really no way to do:
>
> autoload :Foo do
>  require "some/#{interpolated}/value"
> end
>
> I even tried overriding Kernel#require, the way Rubygems does. And
> autoload doesn't seem to use that custom require.

That's not a case of using a library; it's a case of *abusing* a
library.
That's not to say it's "bad", necessarily.  Sometimes, abusing a library
is the right answer.  This is just kind of outside the range of what I
was talking about.  You're referring to what amounts to making *changes*
to the library, and *of course* you have to read the source if you're
going to change it.

I was just talking about using the bloody things.


>
> Now, granted, the Ruby docs can probably be used for much of Rubinius,
> to at least find out what it's supposed to do. But I should stress
> again: MRI has good documentation via rdoc, but I just fell off a cliff
> when it came to extending. Rubinius doesn't have documentation on its
> website at the moment (though it is in the source tree), but I didn't
> need the docs to figure it out.

. . . but good documentation could make it easier.
This topic is locked and can not be replied to.