PDA

View Full Version : Looking For Most Appropriate/Efficient Way Of Resizing A Frameless Window



Sean
21st October 2010, 14:48
Hey guys!

I'm an experienced robotics system developer but rarely write any GUI programs.

I want to write a frameless window with all four sides(borders) and corners resizable, a.k.a top&bottom borders for vertical resizing with mouse cursor "Qt::SizeVerCursor", left&right borders for horizontal resizing with mouse cursor "Qt::SizeHorCursor", and corners for diagonal resizing with mouse cursor "Qt::SizeDiaCursor" just like some skinnable desktop applications.

For this purpose, I have two ideas in mind. One is rewrite the corresponding mouse events and calculate the geometric relationships of the mouse and the window to make it work. The other is to put eight QSizeGrip widgets onto four sides and four corners.

For idea one, I've checked out the implementation code of QSizeGrip and got the idea of what QT guys do. Since they use macros to write difference code for different OSes, if I directly borrow the code then I'm not utilizing the power of portability provided by QT. Therefore, I believe there should be some more portable and/or appropriate way of doing it with available QT infrastructures.

For idea two, I simply couldn't believe that's the right way to achieve my goal.

To be more specific, I'm looking for the "RIGHT" solution from sophisticated GUI programmers for doing this. 'cause I think there must be some de facto widely used routine for this commonly seen task.



For your reference, the characteristics of my window is briefly described as follows.

I inherited the QMainWindow and set the corresponding attributes like the following to make a frameless window.



...
Qt::WindowFlags flags = Qt::Window | Qt::FramelessWindowHint;
setWindowFlags(flags);
setAttribute(Qt::WA_TranslucentBackground);


After that, I use stylesheets to make the window stylish with round corners with Q Style Sheet language similar to the following.



QMainWindow > .QWidget {
border-style: dashed;
border-with: 3px;
border-radius: 6px;
...
}



Thanks in advance!

Regards,
Sean

Sean
25th October 2010, 15:42
Could anyone help with this? Any information will be appreciated!

wysota
25th October 2010, 15:45
What exactly are you having problems with?

Sean
25th October 2010, 15:51
Thanks for the reply!

I'm not familiar with GUI development and I'm trying to write a skinnable window which is frameless but resizable by all its corners and edges. I'm looking for the typical/efficient way a sophisiticated GUI programmer would do.

wysota
25th October 2010, 15:58
You won't make progress by repeating what you have already said. Tell us what have you already tried, what problems have you stumbled upon, etc.

Sean
25th October 2010, 16:16
Sorry if I didn't make my question clear. As I described in #1 of this post, I was able to ahieve my goal of resizing a frameless window. But since I'm not an experienced GUI programmer, I don't know whether those two approaches are the appropriate ones. It's not like I couldn't implement such functionalities, it's just that I highly doubt the two methods I came up with groundlessly were neither proper/efficient for such purposes.

Thanks again for patiently helping me out!

Regards

Added after 6 minutes:

In other words, I want to know whether the methods I came up with are appropriate or not. If not, then what is the proper method to make a frameless window resizable (not just adding one QSizeGrip, but resizable by all four corners and four edges).

Thanks!

wysota
25th October 2010, 16:20
I would probably implement a "charm" that could be applied on a widget consisting of an event filter that would intercept mouse-move events and modify the geometry of the widget. If I wanted to have cursor changes while moving along the borders of the window I would also enable mouse tracking for the widget as part of my charm. One can also check the code for controlling sub-windows of QMdiArea.

Sean
25th October 2010, 16:38
Thanks for your opinion! I care a lot about how much computational resource my algorithm consumes and that's why I posted this thread in the first place. If I keep tracking the mouse inside the window and calculating the corresponding geometry, will that be too much computation for such a simple task? Since the code we write through regular C++/QT statements are user-level code, and there are machine/OS dependent instructions/APIs which utilize hardware acceleration for such purposes. And QT use lots of them internally to improve its efficiency, just like video game developers regularly utilize video card facilities.

wysota
25th October 2010, 17:21
Hardware acceleration or anything like it will not help you determine whether you are at a window border or not. If you want to have such information inside your application, you need mouse tracking. The only alternative is to rely on the windowing system by not applying a custom skin and using the default decorations instead.

genjix
25th October 2010, 17:34
just like video game developers regularly utilize video card facilities.

This is not the case. Engine developers do that and game developers use the engine. In the same way that gui library programmers handle the gritty details and application programmers use the library. Game programming is a large part scripting and setting up events. There's not much 3D programming done apart from writing the odd shader or maybe using a fragment program to speed a physics calculation (in extreme cases).

I can't pretend to know your situation here, but if you're using Qt then likely you're not resource stricken- why are you rolling your own gui? :p

Sean
26th October 2010, 00:59
You are right. I'll track the mouse by myself to implement the resizing code. :)


This is not the case. Engine developers do that and game developers use the engine. In the same way that gui library programmers handle the gritty details and application programmers use the library. Game programming is a large part scripting and setting up events. There's not much 3D programming done apart from writing the odd shader or maybe using a fragment program to speed a physics calculation (in extreme cases).

I can't pretend to know your situation here, but if you're using Qt then likely you're not resource stricken- why are you rolling your own gui? :p

Thanks for your advice! I'm gonna rely on what QT provides. :)