For a sizeable object (https://vaadin.com/api/framework/7.7.3/com/vaadin/server/Sizeable.html), we obtain the width and height using getWidth() and getHeight() respectively, and the unit via getWidthUnit() and getHeightUnit(). How do I set the width/height unit?
EDIT:
So, the reason I ask is because I have a Panel and I'm working on a function that automatically scrolls it to a certain line. The Scrollable interface only provides setScrollTop in terms of pixels, so I would want to do something like:
panel.setScrollTop(lineNumber/totalLines * heightOfPanelInPixels)
For that, I'm planning on using the SizeReporter addon to give me "heightOfPanelInPixels", but I'm not sure I can guarantee the height being in terms of pixels. If it's not, I would need some way to convert the units.
Also, I asked about setting the unit since I thought it was just a universal thing: like if I could just set the unit for all Sizeables to report in, say, inches or pixels
There isn't really any way of achieving what you want to do, short of setting all sizes as px values from the server. For any other kind of size definition, the actual size in pixels will vary depending on lots of different factors that only the browser keeps track of. Furthermore, there isn't any mechanism that would pass back the actual sizes to the server as they are resolved.
You might want try this add-on that makes the size of selected components available on the server: https://vaadin.com/directory/component/sizereporter.
Old answer below:
There are two ways of setting the size in either direction. They both lead to exactly the same end result - it's just two different ways of expressing the same intent.
Taking the height as an example, there's the setHeight(String) method that expects a CSS definition such as 20px or 3.5em. This method is convenient to use of you want to set a hardcoded size directly from code.
The other approach splits up the size into a numerical size and a separate unit: setHeight(float, Unit), e.g. setHeight(20, Unit.PX). This method is more practical if you want to do calculations with the size, e.g. doubling it by using setHeight(2 * getHeight(), getHeightUnit()).
Setting and getting widths also work in exactly the same way.
Related
I built a stereoscopic camera mobile app which performs automatic alignment using findTransformEcc and the app is working pretty well with it. I know I should probably be using rectifyStereoUncalibrated preceded by keypoints and descriptors etc. etc. but I get bad results from that despite many different approaches attempted and I'm super frustrated. So instead, I'm sticking with findTransformEcc (at least for now). At the moment I'm using MotionType.Euclidean (restricted to translations and rotations) but I would like to change that.
So far, the app has worked by having the user take one picture and move to the side to capture the next (chacha method). But now I'm adding the ability to have two phones capture simultaneously. The problem is that the focal length and sensor size (angular field of view) may be different between the two cameras, so in order to align the two pictures I need to allow scaling/zooming. However, if I want to do that with findTransformEcc I can only step up from Euclidean to Affine, it seems like I can't go between. That is, it seems I cannot allow scaling without also allowing shearing, and I don't want shearing.
As another way to explain this, I'd like to get the type of transform that you can get from estimateRigidTranform(array,array,FALSE) (partial affine) but rather than using keypoints as that function does, I want to use findTransformEcc because from my experimentation it just seems to be more reliable.
(https://github.com/KRA2008/crosscam/blob/develop/AutoAlignment/OpenCV.cs is the auto-alignment code if that helps at all)
Take a look at Fourier-Mellin transform based approach: https://github.com/Smorodov/LogPolarFFTTemplateMatcher
It will give you offset, scale and rotation parameters, nothing more.
I've been trying different tiling WM's to see which one best fits my needs. Every time I try a new one, it looks good but I find other things that don't quite work the way I like. My requirements have evolved as I go. Initially, I didn't want to get into Awesome because having to learn Lua is not on my wish list but maybe I should give it a try IF it can do what I want better than the other tiling WM's out there.
I'm going to as specific as I can about what I want. I am running a 3440x1440 monitor. I want to use as much vertical space as possible (meaning, a full width, persistent but mostly empty status bar is not an option, but I do like the notification area and a date/time).
I understand it may not do everything exactly the way I want, which is oke. If it does more or less most of what I want I can weigh my options between Awesome and other tiling WM's (actually, only i3 which is what I'm using now but I'm open to better suggestions). I would very much appreciate it if people don't just say no to something it can't do, but say "no, but it can do ...". In other words, feel free to suggest alternatives that might be helpful as well.
Divide the screen in 3 columns, initially 30/45/25, with the right column split horizontally; Fully adjustable and resizable as needed during my work session;
Persistent layout; when closing the last application in a tile, I don't want that tile to disappear and the remaining tiles to resize. Just show an empty space and leave all tiles as they are.
tabbed tiles, so I see which applications are running in a tile (similar to i3).
Resizable tiles with the keyboard into 1 direction; When making the middle column/tile wider, I want that into a specific direction into another tile and leave the other side alone.
Certain applications I want to always launch into a specific tile. For instance, terminals always go into the right-most column top/bottom, browser/spotify always into the middle, atom/IDE always into the left. Some applications should always be floating. Obviously I want to be able to send them to a different tile after launch.
I don't want a 100% width status bar. It will be mostly empty which is a waste of screen estate. Preferably, I'd like a statusbar part of a tile, for example in the right-most tile, resizing with it. Otherwise I'd like it to be fixed to 30% and allow tiles which are not beneath it to use the full height of the screen. My reason for a statusbar is mute; I actually only want a notification area and a date time permanently visible. I don't need a "start menu", dmenu or similar is perfect, which I believe it has integrated.
Many thanks in advance!
The general answer is "Awesome configuration is code and it can do whatever you want". But there is a catch. Can Awesome be configured like you describe? Yes, totally. There is at least 2 distributions coming close enough (mine[1] and worron[2]) (at least for the tiling workflow, not the look).
The "catch" is that the workflow you describe isn't really the "Awesome way". Awesome is usually used as an automatic tiler. You have layouts that describe a workflow (code, web, internet) and manage the clients according to their programming. Manual tile management is rarely necessary once you have proper layouts. That doesn't mean you can't, I did, but it might be worth thinking outside the box and see if you can automate your workflow a bit further.
Also, the default layout system isn't very modern and makes it hard to implement the features you requested. My layout system (see link below) can be used as a module or as a branch and supports all features described above. Awesome is extremely configurable and it's components can be replaced by modules.
https://github.com/awesomeWM/awesome/pull/644
The layout "serialization" documentation is here:
https://elv13.github.io/libraries/awful.layout.html#awful.layout.suit.dynamic.manual
It is similar to i3 but has more layouts and containers. As for the "leaving blank space" part, it is configured using the fill_strategy:
https://awesomewm.org/doc/api/classes/wibox.layout.ratio.html#wibox.layout.ratio.inner_fill_strategy
As a word of conclusion, I would note that what you ask is "work exactly like i3". If you want such thing, well, use i3. Awesome is a window manager framework. Its goal and purpose is to create a customized desktop shell / WM. If it's what you want, then go ahead and learn it, nothing else can come close to the possibility and the level of control you can get out of it. However it takes time and effort to get to the point where you have "your own perfect desktop". Our users perfect desktops:
https://github.com/awesomeWM/awesome/issues/1395
[1] https://gfycat.com/SmallTerribleAdamsstaghornedbeetle
[2] https://www.youtube.com/watch?v=-yNALqST1-Y
The WM your are looking for is herbstluftwm (hlwm). Its a manual tiling window manager. The tiles which you are talking about are called frames in hlwm. Each frame can contain multiple windows. A frame can also be empty. Only if you kill a frame the other frames will automatically resize. You can add new frames vertically and horizontally and resize them. Each frame can also have a different layout to organize the windows inside. The layout you are looking for is max. This will stack the windows inside a frame on each other. It doesn't show you tabs like i3 however. hlwm allows you to create rules to open certain applications always in certain frames and workspaces. hlwm doesn't have a statusbar buildin. I personally like to use tint2. It can be used as a replacement for your requirement to see running applications as tabs.
I am trying to make a GradientView that is adjustable in Interface Builder. I've been able to get it so I can specify vertical vs horizontal, as well as start/stop colors:
I would like to be able to be able to include intermediate colors as well. Is this possible with the hooks #IBInspectable/#IBDesignable provide?
I could envision a + button which would insert a row there and allow it to accommodate more colors.
(aside: I do wish I would have done this a long time ago, designers seem to throw lots of gradients at me, and I've always open coded them)
Sadly, I don't think you can do that. The IB interface for desigables is quite limited. You can only have single values of a limited number of types. I don't think there is any provision for arrays of things, which is what it sounds like you want.
You might be able to create more than one type of gradient view, each of which takes a different fixed number of colors (e.g. TwoColorGradientView, ThreeColorGradientView, FourColorGraidentView, and FiveColorGradientView). My guess is that a handful of classes would meet the vast majority of your needs.
I don't know a better way to say this, but I'm not looking to change the size of the window. I'm creating a maze, whose size that can be changed via scripting. As such, that may make the maze bigger what the window shows (even on full screen. Is there a way to shrink/enlarge the actual game inside the window?
Well, what you're asking is generally just a bad user experience, cause the size of the game will change, if the maze changes size.
That being said, what you're asking is technically possible. The way to do it would be to use a matrix for SpriteBatch.Begin's last parameter.
This matrix would look something like
Matrix.CreateScale(windowWidth / gameContentTotalWidth, windowHeight / gameContentTotalHeight, 1);
This will scale your game content to always be drawn within the screen. However this means if you make a large maze, you're likely to end up being unable to navigate it, cause you'd be having troubles seeing where you're going.
Recently I've discovered that TCanvas.StretchDraw will not work as expected for object which is a TIcon instance (quick look at TIcon.Draw and DrawIconEx method tells why). Delphi help acknowledges that fact. I know the workaround but I do not know the reason behind such design decision in VCL. Does anyone know why they decided to left TIcon untouched in this matter?
Icons are not regular bitmaps. This is mostly due to historical design and technical reasons.
It did make sense at time when icons were small 32x32 pixels large and 16 colors (good old days!) that icons were never to be stretched on screen.
But there is also a "common sense" technical reason. Such small bitmaps are usually very hard to be re-sized by an algorithm (and default GDI strech algoritm is very fast but produces also very bad result in respect to other interpolation modes, e.g. available with GDI+), so it was decided to embed a set of icons within the executable, as resources: one icon per size. The strech process benefits of being done at design time, at pixel level, by an icon designer. And - back those days - it was also much less resource consuming to use dedicated icons, with a reduced color palette.
Since you are supposed to have a set of icons with a pre-defined size for each, you do not need to use StrechDraw, but just select the right icon to display.
So if you want to display an icon with a given size, ensure you pickup the right size, or get the biggest icon and upsize it, using a temporary bitmap - or DrawIconEx(). Or, even better, do not use icons, but a bitmap, or a vectorial drawing if you expect huge picture size.