Comments (15)
+1
:height
and :width
should be the usable area of the window, and should not include chrome (especially since the chrome size could vary lots among platforms)
from shoes4.
:height
and:width
should be the usable area of the window
Totally agree. So, one more question. How to get the chrome size in SWT?
from shoes4.
@ashbb I guess you could subtract the current App.width
and height
from the values you get out of Shell.getSize
(from the way I understand it, getSize() will return the Shell's width and height).
from shoes4.
@davorb You are right. But, I think that Shell's height is y_1 in your screenshot.
We need to know the size of usable area, i.e. y_2. So, I said "How to get the chrome size (i.e. y_1 - y_2)?"
Do you know the way to get y_2 instead of y_1?
from shoes4.
@ashbb I just tested it out and getSize
basically works as I said. It prints out y_2.
I think the entire bugfix to this is basically:
def height
gui_container.getSize.y
end
def width
gui_container.getSize.x
end
EDIT: Of course you'll need to add code for setting the height and width
from shoes4.
Am I wrong or wouldn't this also fix #52 ?
I think we should wait with this fix until we can merge the changes from @ashbb (not necessarily but that would limit the merge efforts).
from shoes4.
This is an interesting architectural question. @davorb you are suggesting that we use backend (Swt) values to define values (i.e. height and width) that we get out of the DSL layer. This makes complete sense, since it is the backend that paints the pixels.
However, I have so far been working the opposite way: keeping all of those values in the DSL layer, and making the backend adjust to those values. The reasoning for this is that it should allow multiple backends to work more similarly, because they are all using the same Shoes values.
I envision something like (untested)
# lib/shoes/app.rb
def height=(h)
@height = h
@gui.height = h
end
# lib/shoes/swt/app.rb
def height=(h)
# ensure that y_2 == h, and let the chrome size be what it will
end
Thoughts on this? @ashbb @pjfitzgibbons @PragTob @steveklabnik @alindeman
from shoes4.
Oh, two topics. :)
@davorb, @PragTob Umm,.. may be platform-dependent problem. Try out the following snippet and watch this. At least in Windows 7, shell.getSize
is not y_2. :(
require 'java'
require 'swt'
module Swt::Events
import org.eclipse.swt.events.PaintListener
end
display = Swt::Widgets::Display.new
shell = Swt::Widgets::Shell.new display, Swt::SWT::SHELL_TRIM
shell.setLayout Swt::Layout::RowLayout.new
shell.setSize 600, 500
shell.addListener Swt::SWT::Close, proc{Swt.display.dispose}
pl = Swt::Events::PaintListener.new
class << pl; self end.
instance_eval do
define_method :paintControl do |e|
e.gc.drawLine 0, 0, 600, 500
end
end
shell.addPaintListener pl
b = Swt::Widgets::Button.new shell, Swt::SWT::PUSH
b.setText 'shell.getSize'
b.addSelectionListener do |e|
pos = shell.getSize
p [pos.x, pos.y]
end
shell.open
Swt.event_loop{Swt.display.isDisposed}
@wasnotrice I agree that we separate the DSL layer from the backend layer. But, I have a question. Why is it necessary to KEEP all of those values in the DSL layer? Isn't the following enough?
# lib/shoes/app.rb
def height
@gui.height
end
def height=(h)
@gui.height = h
end
# lib/shoes/swt/app.rb
def height
# return y_2
end
def height=(h)
# ensure that y_2 == h
end
from shoes4.
@ashbb No, I'm sorry. You are of course correct.
from shoes4.
@davorb Thanks for the information. Try out the following snippet again. It it works well on all platforms, we found a solution shell.pack
. :)
require 'java'
require 'swt'
module Swt::Events
import org.eclipse.swt.events.PaintListener
end
display = Swt::Widgets::Display.new
shell = Swt::Widgets::Shell.new display, Swt::SWT::SHELL_TRIM
shell.setLayout Swt::Layout::RowLayout.new
shell.addListener Swt::SWT::Close, proc{Swt.display.dispose}
cs = Swt::Widgets::Composite.new shell, Swt::SWT::NULL
cs.setLayoutData Swt::Layout::RowData.new(600, 500)
cs.setLayout Swt::Layout::RowLayout.new
cs.set_background display.getSystemColor(Swt::SWT::COLOR_RED)
pl = Swt::Events::PaintListener.new
class << pl; self end.
instance_eval do
define_method :paintControl do |e|
e.gc.drawLine 0, 0, 600, 500
end
end
cs.addPaintListener pl
b = Swt::Widgets::Button.new cs, Swt::SWT::PUSH
b.setText 'getSize'
b.addSelectionListener do |e|
spos, cpos = shell.getSize, cs.getSize
p "shell: #{[spos.x, spos.y]}, cs: #{[cpos.x, cpos.y]}"
end
shell.pack
shell.open
Swt.event_loop{Swt.display.isDisposed}
from shoes4.
I'm getting shell: [622, 544], cs: [600, 500]
in Windows 7. I think that the real size of the chrome is around ~28 pixels.
Can the difference in width really be 44 pixels? That seems like a lot.
from shoes4.
@davorb Thanks for confirmation.
Can the difference in width really be 44 pixels? That seems like a lot.
You are right. I think the difference in width really is about 38 pixels.
But no problem. Because in the above snippet, there are margin-spaces in default. We'll be able to remove the default margin-spaces (meaning: set margin-zero) in Shoes 4. ;-)
from shoes4.
@wasnotrice I agree that we separate the DSL layer from the backend layer. But, I have a question. Why is it necessary to KEEP all of those values in the DSL layer?
@ashbb it isn't necessary to keep values in the DSL layer. I was just commenting that, so far, that's where those values are. I think it's totally reasonable to delegate them to the GUI layer. We just have to have a good spec in place, so that other implementations give the same results. And we have to be consistent across the project :)
from shoes4.
it isn't necessary to keep values in the DSL layer.
Okay. Thanks for the reply.
@davorb Can you close this thread? Or need more discussion?
from shoes4.
Wait... so what did we actually decide? To keep it the way it is or to change it?
from shoes4.
Related Issues (20)
- Included files aren't found by the app HOT 2
- Poignant Guide / Nobody Knows Shoes link problem HOT 3
- bootup time of a simple app HOT 1
- No gems found matching '' HOT 2
- Using "link" breaks the app HOT 5
- Try out Travis Windows build environment?
- mac install error HOT 1
- package problem with music
- Need an Invite HOT 1
- Shoes overwrites the Windows environment variable HOT 3
- HiDPI Displays
- Image Clearing HOT 2
- nokogiri gem is unstable HOT 1
- Not able to drag windows? HOT 7
- No route to host on installing gem HOT 4
- Is this project dead? HOT 2
- Cannot install Ruby Shoes 4 HOT 14
- Comodos
- Roll Call - users / developers / "Is this thing on?" HOT 5
- Shoes joining forces with Glimmer? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from shoes4.