N
nukleus
Finally, after waiting for three days for it to swap the
Universe, I gathered enough courage to push that magic
help button, trying to get an answer on why my buttons
simply dissapear in run mode, while they are perfectly
visible and of correct size in the design mode.
Why by increasing some coefficients some GUI elements
DECREASE their size?
Why some of my text fields become even smaller than
the Y size of the font?
So...
Here we go, the "explanation" from one of the leading
players in the Java field, Borland...
You just have to wait a couple of hours
so that i could cut and paste the text directly
from their "help" subsystem...
:--}
Ladies, Gents and assorted bio-robots,
here is the holey word of Borland JBuilder:
(The original text is idented)
A component can completely fill up its display area
[and we haven't even started yet.
What OTHER areas does the component have?
What DOES it mean a "display area" for a GUI element?
Does it have some trans-galactic areas also?
Hello, planet Mars.]
(as with component "4" in the example above),
or it can be smaller than its display area.
Wut?
Can any of the smart experts around here can
please essplain to me how is it possible,
even in principle, for something to have a smaller
size than its "display area"?
Then what IS this magic "display area" on the first place?
WHat IS the difference between a button as a GUI element,
and its "display area"?
Are these people on drugs?
Anybody has a clue what these "architects" are talking
about? I just never heard of such things. Sorry.
For example, in the following GridBagLayout container,
the display area for component "3" consists of nine cells,
three horizontally and three vertically.
However, the component is smaller than the display area
because it has insets which create a margin between the
edges of the display area and the component
Fine, we can swallow this much.
But we are already wasting some time on this stupid lil thingy.
Ok, and next?
Even though this component has both horizontal and vertical
fill constraints, since it also has insets on all four sides
How can enlargement be called a constraint?
Anybody has any clue?
Constraint means limitation of scope.
So, pretty much, from the second paragraph,
we are asked to look at the world,
standing upside down, and we haven't gotten
a SINGLE piece of useful information so far.
of the component (represented by the double blue nibs on each
side of the display area),
You know, mr. Borland, at this junction, the last thing
i want to hear is this "double blue nibs", which is a
completely insane trip on its own, cause i have a clue
of what you are talking about. Just try to drag some of those
lil square boxes. Your hair may stand up. Never seen anything
like that. When you try to ENLARGE things, they become smaller.
Sure, some super smart inter gallactic technology of suckology
i guess.
these take precedence over the fill constraints.
WHO takes precedence over themselves?
You are talking about those very fill constraints.
Haven't you noticed?
You must be smoking that strong grass from the
Silicon Valley.
Here is your first sentence:
"Even though this component has both horizontal and vertical
fill constraints"
So, what are we talking about here again?
Which constraints are taking a precedence over themselves again?
Sorry, I can't grasp what you are talking about zo far.
The result is
The result of what?
that the component only fills the display area
Oh, thanks God!
I was afraid its going to fill my entire room here.
up to the insets.
Oh yeah!
Sure!
If you are not going to touch those lil blue squares,
and don't even think of touching those black lil squares,
cause you puter may fry. And don't try to think that
by dragging your window size to make it larger,
it MUSt increase its size,
just because you are dragging it to do so.
You are simply unswivilized lil biorobot,
thinking that if you add things the result becomes bigger.
But not to worry. You'll learn how to see the world
standing upside down.
Fine.
zo far,
zo good.
And then?
If you try to make the component larger than its current
display area,
By doing what?
By changing a sorce code?
Or by dragging something on the GUI designer screen?
GridBagLayout increases the size of the cells in the
display area
What is DISPLAY AREA?
Display area of what?
Do you mean the "display area" to be my puter's screen?
Do you mean it to be the bother area of a stupid lil button?
Do you mean the virtual, super-continental,
fully "constrained", while at the same time, expanded
something?
Am i doing a graphical gui design
or talking to a madman?
to accommodate the new size of the component
I mean are you people insane?
Why do you need to put all these extra blabber words
into something that OUGHT to be the simpliest thing
imaginable.
Why don't you say it like this:
If you want to increase the size of you stupid lil
button, just drag that lil blue square thing.
Simple as that.
You don't even have to say this stupid stuff
you are saying, cause it ought to be simply
obvious by the context of what you are doing.
Do you have to tell people:
If you want to walk, first, you have to lift
your leg and than move it forward,
and don't forget to put it back on the ground?
Now, we are talking about the "display areas",
and it isn't even clear if it is a button border
boundary or your virtual and purely conceptual
idea of some abstract "display area".
and leaves space for the insets.
Thanks God!
Where does who leave what space?
By doing what?
It happens when?
How do I enter that space?
Where?
When you modify your source code and that stupid
annonymous thing you automatically generated?
Or while you are dragging your button boundaries?
A component can also be smaller than its display area
How?
How many joints did you smoke today?
The component can not have size smaller than its
"display area". It can ONLY be the size of that area.
The "display area" you are talking about MUST be
the grid bag constraint area for that particular cell,
and if you are talking about a group of cells,
than it can not be a component's display area,
as, at that point, it isn't even clear what do you
mean by "component".
My table can not have smaller size than it actually
has, regardless of your concept of "display area".
How that area is defined on the first place?
Are you familiar with the simpliest concepts
of left, right, top and bottom margins,
used by virtually any mortal on the planet Earth?
Why do you need to invent this "display area" thing
that it is not even clear what do you mean by that?
when there are no insets,
Uhu.
Try to connect that with a previous sentence.
You'll go nuts.
Now, how can there be no insets,
if i set those insets in your own dialog box?
What happens to my insets parameters
when i change what to what?
Here is the beginning of your own sentence:
"A component can also be smaller than its display area
when there are no insets".
Ok, but where did those insets go?
Secondly, how can something become smaller
than its "display area", when there are no margins?
Are you on morphine, by ANY chance?
Do you think people walk on their EARS?
as with component "6" in the following example
Well, if you look at that picture,
your ear drums may be slighly popping.
Even though the display area is only one cell,
(This man must be obscessed with this magic "display area")
there are no constraints that enlarge the component
Huh?
Does this suppose to actually mean something?
beyond its minimum size.
Fine. And where do i set the minimum size of it?
You see, in your dialog box there isn't even a concept
of a "minimu size" or "preferred size".
There are only fill margins, and even that much isn't
clear, cause those margins may or may not include the
text X and Y size of the actual text that you want
to be displayed as default in that component.
Just try to change text of your button,
and you'll see how, by some magic power, the button
gets larger.
So...
Where do you enter that "minimum size"?
You see, I am busy with all sorts of things
up to my ears, and you are talking utter lunacy
so far, and i have not a sligtest clue of what
you are talking about.
The things you claim exist, do not actually exist,
at least in your own GUI design tools.
And it is not clear which constraint parameters,
that are not constraints on the first place,
correspond to the minimal and preferred component sizes
and how these things are rendered
and what is relationship between the rendering
size and the sizes you made while designing your frames.
In my view, what you designed with a design tool,
should look EXACTLY the same as when you run this
code, which is not the case with your gadgets.
When I design it, i see one thing,
but when I execute the code, i see a TOTALLY
different thing. Not only that, but some perfectly
valid text fields, buttons, and you name it,
simply dissapear, or become of a microscopic size.
Why?
What is the problem with all this stupid stuff
on the first place?
What kind of "technology" is this?
In this case, the width of the display area is
No wonder people go kill the innocent postmen!
Hearing this "display area" trip about ten times
in one sentence and not getting a SINGLE bit
of useful information as to WHY in hell his
buttons dissapear in run time, when they are
perfectly visible and correct in design time,
one may start thinking about greasing his
good ole Colt 45.
Why the hell is text fields are two microns in Y
size? How can ANY text field in a world of anything,
even remotely resembling sanity,
be smaller than the size of a font?
What kind of technology is this?
How can you possibly make it smaller than
the smallest thing there is, which is button
label or text field text?
WHERE did you learn this kind of "technology"?
In a mad house?
Sure, after reading all this "help",
one may start thinking about his good ole Colt 45,
sitting in his drawer, and about the first thing
that comes to his mind, for some strange reason,
is a postman!
Wut?
Yep, a POSTMAN!
He wants to kill a postman,
and not that sadist that created all this bloatware
and all those "help" files.
Why postman?
Cause he can't get his hands on Willy's troath!
determined by the larger components above
Yup, Tell me about it.
Just ten more times.
Cause I feel bored like hell
reading all this...
Well...
it in the same column.
Hopefully.
Component "6" is displayed at its minimum size,
WHERE IS THAT MINIMUM SIZE SET?
and since it is smaller than its display area,
Jesus!
Where is my gun?
it is anchored at the west edge of the display area
MAAAAAN!
Ima gonna send a trans-continental-innerballistic,
fully super-nukelar powered rocket of da biggest size
there is to the places where you sit
if i hear about this sub-idiotic "display area",
not related to anything based in reality,
one more time.
with an anchor constraint.
Uhu.
And WHERE to you set that?
As you can see,
Yep.
I am ALREADY seeing it.
Holy ghost,
holy ghost,
anybody home?
GridBagConstraints play a critical role in GridBagLayout.
Yep, I do see that.
Not only that, but they play a CRITICAL role
in my personal life at this moment.
Cause you are but a bunch of biorobots,
brainwashed to oblivion, it seems.
What planet are you from anyway?
We'll look at these constraints
What sucky constraints are you talking about?
I haven't been able to connect a SINGLE word of
yours to your own previous words.
in detail in the next topic,
Oh yes, I am sure of that.
And then?
"About GridBagConstraints".
Hold on, you lil cockroach.
Where is the information about da gridbags?
What are you, a thief?
That morphine is no good?
I have waited for about three days
till you swap da Universe itself,
just to get "help" on this stupid lil thing
you call gridbag, that should not be even mentioned
in the modern technology of suckology,
cause just about ALL you need to do,
is click on things and drag their sizes,
without even bothering about "constrains",
that are not constrains on the first place,
those "insets", which is a pile of horseshit,
and of the lowest grade, as they are simply
margins as known to mortals.
I dont want to know about this "fill size" crap,
which is about the sickest thing imaginable,
as when you design things with your gui designer,
you do not think of what is left after you type
text into your button label or a text field.
You think in terms of its size and proportions
to other things in your design.
And when you set something to 0,
it means it does not exist,
and when you set something to 1.0,
it means that just about the only thing that exists
is it. And when you reduce it from 1.0 to 0.9,
you expect it to become smaller,
and when you increase it from 0.0 to 0.1,
you expect the opposite.
Things like that.
Why in hell do I have to bother about all this
insanity even using the most "sophisticated"
tools there are, as you claim?
Why can't I simply drag and drop and forget about this thing?
Why do I have to spend weeks on designing plain,
ordinary GUI?
Can't you just automatically generate the source
code without even telling me all this crap?
What is this farse about?
WHERE IS THAT HELP YOU PROMISED ME?
This utterly confused crap you call a description
of one of the most complicated layout gadgets there are?
And you expect to remain in business?
For how long do you think?
You are just a bunch of sadists.
That is all.
Nothing less.
Nothing more...
And you are not architects of ANY kind.
My neighbor shue maker
is a better architect then all of you combined.
And you'd better take your technical writers
off those heavy drugs.
Summary: there isn't a single useful bit of information
in all this "help" stuff.
It isn't clea what is cell,
what is button
and what is what.
Simple things are placed upside down.
And description of one of the most complex things
in layouts is virtually abscent.
It is not clear what happens when you set
the weights to 0 or 1.0.
It isn't clear what happens when you set
"Size padding" to N value, and what does that N
value represent and how does it affect rendering.
It isn't clear what happens when you enable
X and Y fills and how does it affect rendering.
In fact, there isn't even a SINGLE BIT of
useful information that makes ANY sense
in any world that even remotely resembles reality.
Furthermore, when you try to compile that code,
you may get an error message that your package
name you declared in the beginning of your
sorce file, does not exist! How could this possibly be?
And even if it compiles, it may complain that
it does not exist in the run time.
But how did you compile it on the first place?
Do the source files exist?
Yup. They MUST be, otherwise you couln't compile.
And if you finishe a compilation and claimed
there are no errors, how come this thing
does not run and you claim that the MAIN class
does not even exist?
I look at the source and it is there.
I look at project configuration parameters
and they are EXACTLY as you set in your own
Welcome app.
Zo...
What am I supposed to do with this kind of
"advanced technology", hailed by some as about
the best thing there is under the Sun?
How much you had to bribe those reviewers
to write their ejaculating reviews about this crap?
Or are they on a payroll?
Zee ya.
Universe, I gathered enough courage to push that magic
help button, trying to get an answer on why my buttons
simply dissapear in run mode, while they are perfectly
visible and of correct size in the design mode.
Why by increasing some coefficients some GUI elements
DECREASE their size?
Why some of my text fields become even smaller than
the Y size of the font?
So...
Here we go, the "explanation" from one of the leading
players in the Java field, Borland...
You just have to wait a couple of hours
so that i could cut and paste the text directly
from their "help" subsystem...
:--}
Ladies, Gents and assorted bio-robots,
here is the holey word of Borland JBuilder:
(The original text is idented)
A component can completely fill up its display area
[and we haven't even started yet.
What OTHER areas does the component have?
What DOES it mean a "display area" for a GUI element?
Does it have some trans-galactic areas also?
Hello, planet Mars.]
(as with component "4" in the example above),
or it can be smaller than its display area.
Wut?
Can any of the smart experts around here can
please essplain to me how is it possible,
even in principle, for something to have a smaller
size than its "display area"?
Then what IS this magic "display area" on the first place?
WHat IS the difference between a button as a GUI element,
and its "display area"?
Are these people on drugs?
Anybody has a clue what these "architects" are talking
about? I just never heard of such things. Sorry.
For example, in the following GridBagLayout container,
the display area for component "3" consists of nine cells,
three horizontally and three vertically.
However, the component is smaller than the display area
because it has insets which create a margin between the
edges of the display area and the component
Fine, we can swallow this much.
But we are already wasting some time on this stupid lil thingy.
Ok, and next?
Even though this component has both horizontal and vertical
fill constraints, since it also has insets on all four sides
How can enlargement be called a constraint?
Anybody has any clue?
Constraint means limitation of scope.
So, pretty much, from the second paragraph,
we are asked to look at the world,
standing upside down, and we haven't gotten
a SINGLE piece of useful information so far.
of the component (represented by the double blue nibs on each
side of the display area),
You know, mr. Borland, at this junction, the last thing
i want to hear is this "double blue nibs", which is a
completely insane trip on its own, cause i have a clue
of what you are talking about. Just try to drag some of those
lil square boxes. Your hair may stand up. Never seen anything
like that. When you try to ENLARGE things, they become smaller.
Sure, some super smart inter gallactic technology of suckology
i guess.
these take precedence over the fill constraints.
WHO takes precedence over themselves?
You are talking about those very fill constraints.
Haven't you noticed?
You must be smoking that strong grass from the
Silicon Valley.
Here is your first sentence:
"Even though this component has both horizontal and vertical
fill constraints"
So, what are we talking about here again?
Which constraints are taking a precedence over themselves again?
Sorry, I can't grasp what you are talking about zo far.
The result is
The result of what?
that the component only fills the display area
Oh, thanks God!
I was afraid its going to fill my entire room here.
up to the insets.
Oh yeah!
Sure!
If you are not going to touch those lil blue squares,
and don't even think of touching those black lil squares,
cause you puter may fry. And don't try to think that
by dragging your window size to make it larger,
it MUSt increase its size,
just because you are dragging it to do so.
You are simply unswivilized lil biorobot,
thinking that if you add things the result becomes bigger.
But not to worry. You'll learn how to see the world
standing upside down.
Fine.
zo far,
zo good.
And then?
If you try to make the component larger than its current
display area,
By doing what?
By changing a sorce code?
Or by dragging something on the GUI designer screen?
GridBagLayout increases the size of the cells in the
display area
What is DISPLAY AREA?
Display area of what?
Do you mean the "display area" to be my puter's screen?
Do you mean it to be the bother area of a stupid lil button?
Do you mean the virtual, super-continental,
fully "constrained", while at the same time, expanded
something?
Am i doing a graphical gui design
or talking to a madman?
to accommodate the new size of the component
I mean are you people insane?
Why do you need to put all these extra blabber words
into something that OUGHT to be the simpliest thing
imaginable.
Why don't you say it like this:
If you want to increase the size of you stupid lil
button, just drag that lil blue square thing.
Simple as that.
You don't even have to say this stupid stuff
you are saying, cause it ought to be simply
obvious by the context of what you are doing.
Do you have to tell people:
If you want to walk, first, you have to lift
your leg and than move it forward,
and don't forget to put it back on the ground?
Now, we are talking about the "display areas",
and it isn't even clear if it is a button border
boundary or your virtual and purely conceptual
idea of some abstract "display area".
and leaves space for the insets.
Thanks God!
Where does who leave what space?
By doing what?
It happens when?
How do I enter that space?
Where?
When you modify your source code and that stupid
annonymous thing you automatically generated?
Or while you are dragging your button boundaries?
A component can also be smaller than its display area
How?
How many joints did you smoke today?
The component can not have size smaller than its
"display area". It can ONLY be the size of that area.
The "display area" you are talking about MUST be
the grid bag constraint area for that particular cell,
and if you are talking about a group of cells,
than it can not be a component's display area,
as, at that point, it isn't even clear what do you
mean by "component".
My table can not have smaller size than it actually
has, regardless of your concept of "display area".
How that area is defined on the first place?
Are you familiar with the simpliest concepts
of left, right, top and bottom margins,
used by virtually any mortal on the planet Earth?
Why do you need to invent this "display area" thing
that it is not even clear what do you mean by that?
when there are no insets,
Uhu.
Try to connect that with a previous sentence.
You'll go nuts.
Now, how can there be no insets,
if i set those insets in your own dialog box?
What happens to my insets parameters
when i change what to what?
Here is the beginning of your own sentence:
"A component can also be smaller than its display area
when there are no insets".
Ok, but where did those insets go?
Secondly, how can something become smaller
than its "display area", when there are no margins?
Are you on morphine, by ANY chance?
Do you think people walk on their EARS?
as with component "6" in the following example
Well, if you look at that picture,
your ear drums may be slighly popping.
Even though the display area is only one cell,
(This man must be obscessed with this magic "display area")
there are no constraints that enlarge the component
Huh?
Does this suppose to actually mean something?
beyond its minimum size.
Fine. And where do i set the minimum size of it?
You see, in your dialog box there isn't even a concept
of a "minimu size" or "preferred size".
There are only fill margins, and even that much isn't
clear, cause those margins may or may not include the
text X and Y size of the actual text that you want
to be displayed as default in that component.
Just try to change text of your button,
and you'll see how, by some magic power, the button
gets larger.
So...
Where do you enter that "minimum size"?
You see, I am busy with all sorts of things
up to my ears, and you are talking utter lunacy
so far, and i have not a sligtest clue of what
you are talking about.
The things you claim exist, do not actually exist,
at least in your own GUI design tools.
And it is not clear which constraint parameters,
that are not constraints on the first place,
correspond to the minimal and preferred component sizes
and how these things are rendered
and what is relationship between the rendering
size and the sizes you made while designing your frames.
In my view, what you designed with a design tool,
should look EXACTLY the same as when you run this
code, which is not the case with your gadgets.
When I design it, i see one thing,
but when I execute the code, i see a TOTALLY
different thing. Not only that, but some perfectly
valid text fields, buttons, and you name it,
simply dissapear, or become of a microscopic size.
Why?
What is the problem with all this stupid stuff
on the first place?
What kind of "technology" is this?
In this case, the width of the display area is
No wonder people go kill the innocent postmen!
Hearing this "display area" trip about ten times
in one sentence and not getting a SINGLE bit
of useful information as to WHY in hell his
buttons dissapear in run time, when they are
perfectly visible and correct in design time,
one may start thinking about greasing his
good ole Colt 45.
Why the hell is text fields are two microns in Y
size? How can ANY text field in a world of anything,
even remotely resembling sanity,
be smaller than the size of a font?
What kind of technology is this?
How can you possibly make it smaller than
the smallest thing there is, which is button
label or text field text?
WHERE did you learn this kind of "technology"?
In a mad house?
Sure, after reading all this "help",
one may start thinking about his good ole Colt 45,
sitting in his drawer, and about the first thing
that comes to his mind, for some strange reason,
is a postman!
Wut?
Yep, a POSTMAN!
He wants to kill a postman,
and not that sadist that created all this bloatware
and all those "help" files.
Why postman?
Cause he can't get his hands on Willy's troath!
determined by the larger components above
Yup, Tell me about it.
Just ten more times.
Cause I feel bored like hell
reading all this...
Well...
it in the same column.
Hopefully.
Component "6" is displayed at its minimum size,
WHERE IS THAT MINIMUM SIZE SET?
and since it is smaller than its display area,
Jesus!
Where is my gun?
it is anchored at the west edge of the display area
MAAAAAN!
Ima gonna send a trans-continental-innerballistic,
fully super-nukelar powered rocket of da biggest size
there is to the places where you sit
if i hear about this sub-idiotic "display area",
not related to anything based in reality,
one more time.
with an anchor constraint.
Uhu.
And WHERE to you set that?
As you can see,
Yep.
I am ALREADY seeing it.
Holy ghost,
holy ghost,
anybody home?
GridBagConstraints play a critical role in GridBagLayout.
Yep, I do see that.
Not only that, but they play a CRITICAL role
in my personal life at this moment.
Cause you are but a bunch of biorobots,
brainwashed to oblivion, it seems.
What planet are you from anyway?
We'll look at these constraints
What sucky constraints are you talking about?
I haven't been able to connect a SINGLE word of
yours to your own previous words.
in detail in the next topic,
Oh yes, I am sure of that.
And then?
"About GridBagConstraints".
Hold on, you lil cockroach.
Where is the information about da gridbags?
What are you, a thief?
That morphine is no good?
I have waited for about three days
till you swap da Universe itself,
just to get "help" on this stupid lil thing
you call gridbag, that should not be even mentioned
in the modern technology of suckology,
cause just about ALL you need to do,
is click on things and drag their sizes,
without even bothering about "constrains",
that are not constrains on the first place,
those "insets", which is a pile of horseshit,
and of the lowest grade, as they are simply
margins as known to mortals.
I dont want to know about this "fill size" crap,
which is about the sickest thing imaginable,
as when you design things with your gui designer,
you do not think of what is left after you type
text into your button label or a text field.
You think in terms of its size and proportions
to other things in your design.
And when you set something to 0,
it means it does not exist,
and when you set something to 1.0,
it means that just about the only thing that exists
is it. And when you reduce it from 1.0 to 0.9,
you expect it to become smaller,
and when you increase it from 0.0 to 0.1,
you expect the opposite.
Things like that.
Why in hell do I have to bother about all this
insanity even using the most "sophisticated"
tools there are, as you claim?
Why can't I simply drag and drop and forget about this thing?
Why do I have to spend weeks on designing plain,
ordinary GUI?
Can't you just automatically generate the source
code without even telling me all this crap?
What is this farse about?
WHERE IS THAT HELP YOU PROMISED ME?
This utterly confused crap you call a description
of one of the most complicated layout gadgets there are?
And you expect to remain in business?
For how long do you think?
You are just a bunch of sadists.
That is all.
Nothing less.
Nothing more...
And you are not architects of ANY kind.
My neighbor shue maker
is a better architect then all of you combined.
And you'd better take your technical writers
off those heavy drugs.
Summary: there isn't a single useful bit of information
in all this "help" stuff.
It isn't clea what is cell,
what is button
and what is what.
Simple things are placed upside down.
And description of one of the most complex things
in layouts is virtually abscent.
It is not clear what happens when you set
the weights to 0 or 1.0.
It isn't clear what happens when you set
"Size padding" to N value, and what does that N
value represent and how does it affect rendering.
It isn't clear what happens when you enable
X and Y fills and how does it affect rendering.
In fact, there isn't even a SINGLE BIT of
useful information that makes ANY sense
in any world that even remotely resembles reality.
Furthermore, when you try to compile that code,
you may get an error message that your package
name you declared in the beginning of your
sorce file, does not exist! How could this possibly be?
And even if it compiles, it may complain that
it does not exist in the run time.
But how did you compile it on the first place?
Do the source files exist?
Yup. They MUST be, otherwise you couln't compile.
And if you finishe a compilation and claimed
there are no errors, how come this thing
does not run and you claim that the MAIN class
does not even exist?
I look at the source and it is there.
I look at project configuration parameters
and they are EXACTLY as you set in your own
Welcome app.
Zo...
What am I supposed to do with this kind of
"advanced technology", hailed by some as about
the best thing there is under the Sun?
How much you had to bribe those reviewers
to write their ejaculating reviews about this crap?
Or are they on a payroll?
Zee ya.