Madodate 3D Window Clone

[BillionNamesofGod]

Has anybody used Madodate 3D windows for winXP? (source code availabe but only for windowsXP)

This really is the most useful way to manage windows in 3D, much better than 3D cube
or any other 3D management metaphor! It really works !

I'm still in shock why no-one has picked up on this way of doing things.
The desktop it self become a 3D space (like inside the cube) and windows are flipped to the side,
you can easily access them, as they are right on the edge. Bloody brilliant. It's the only reason why I've not moved to linux or mac, no-one has this.

would it be possible to have this in the new version? I really need to get away from winXP.

see:

http://davc73.free.fr/madotate/ScreenShot.jpg

http://bikerscafe.org/uf7/forum/viewtopic.php?p=119#119

[Jupiter]

hah
been using it for a couple of months now with my winxp
[url=http://img264.imageshack.us/my.php?image=madodateme6.jpg:4c2e9]http://img264.imageshack.us/img264/3813/madodateme6.th.jpg[/url:4c2e9]

EDIT: I might add... Nothing i have ever seen on/for windows can hold a candle to
Linux/Compiz

[aok]

I like it! I'm not sure how I'd use it yet, but I'm sure I will figure it out.

Currently I use Scale and the Cube to manage all my stuff. I've gotten very used to this setup while I work.

I think I could use the Madodate style way for a single viewport for when I do stuff that needs to switch windows/applications a lot. Things like system/network administration...RDesktop, VNC, xterms, ssh, etc.

Then I'd probably use my old-style Scale+Cube when I am doing development...where I use each cube-face for a specific purpose where I normally run applications maximized or need to have windows use up as much screen as I can cram...one for documentation, one for Eclipse, etc.

[BillionNamesofGod]

great so that's 3 people who thinks it's a great idea.

It's actually been around in GUI research for years and years, and frankly the first thing I expected to be implemented in these new openGL guis - but I'm still waiting!!

So how do we get this implemented - any programmers out there want to help?


see: this scren below is from 1996 YES 1996, this was come up with! it's 2007 and I'm still waiting !!!!

Elements of a Three-dimensional Graphical User Interface


http://goanna.cs.rmit.edu.au/~gl/research/HCC/img5.gif

[url:26a99]http://goanna.cs.rmit.edu.au/~gl/research/HCC/interact97.html[/url:26a99]

[Jupiter]

So how do we get this implemented - any programmers out there want to help?


what do you mean by "get it implemented"
do you mean in Linux? Like Project Looking Glass http://www.sun.com/software/looking_glass/
There are other's that do this too

or do you mean in the new Compcomm?
I personally think the mindows plugin "Miniwin" was way better idea
and a lot more usefull as it was live mini windows "not static images"
adjustments included, size, opacity, location on screen
mindows on the left side of screen in this screenshot
[url=http://img160.imageshack.us/my.php?image=mindowspq7.jpg:f5f87]http://img160.imageshack.us/img160/5475/mindowspq7.th.jpg[/url:f5f87]
i don't have a screenshot of the group mode of mindows but, on mouse over
the windows in a group would fly out in a circle so you could see each one and choose

[some-guy]

Metisse is for linux, but cant work with compiz/beryl :cry: http://insitu.lri.fr/metisse/

EDIT: Mandriva has it in some special version now...

[some-guy]

Yod'm 3d will give you a cube in M$ windows :roll: ...

beryl/compiz beats it any day though :mrgreen:

[Jupiter]

[quote="some-guy":279f0]
Yod'm 3d will give you a cube in M$ windows :roll: ...

beryl/compiz beats it any day though :mrgreen:
[/quote:279f0]

BIGTIME
I've been working with windows since version 1 "i still have my diskettes" LOL
and as i stated earlier in this post
[quote:279f0]
Nothing i have ever seen on/for windows can hold a candle to
Linux/Compiz
[/quote:279f0]

[davim]

I would really like to see this implemented as a plugin for Compcomm. :)

[BillionNamesofGod]

So how do we get this implemented - any programmers out there want to help?


what do you mean by "get it implemented"


I don't think you have any understanding whatsoever what this forum is about.
It's about the beryl/compiz opengl GUI onlinux and improving it. This thread is about suggesting new
features, I just suggested one.

I suggested we have this feature and looking for programmers to implement it into beryl/compiz for linux.

You really need to **WAKE UP** and understand what this forum is about. Jesus and I thought you knew what I was talking about!

Seriously man, you reply, makes me think you shouldn't be here at all, you just don't get it. Really dissappointing you are turning my suggestion into a farce. It's not, it's deadly serious. I want to see this feature in Beryl Compiz.

So please get with the programme.

[Jupiter]

So how do we get this implemented - any programmers out there want to help?


what do you mean by "get it implemented"


I don't think you have any understanding whatsoever what this forum is about.
It's about the beryl/compiz opengl GUI onlinux and improving it. This thread is about suggesting new
features, I just suggested one.

I suggested we have this feature and looking for programmers to implement it into beryl/compiz for linux.

You really need to **WAKE UP** and understand what this forum is about. Jesus and I thought you knew what I was talking about!

Seriously man, you reply, makes me think you shouldn't be here at all, you just don't get it. Really dissappointing you are turning my suggestion into a farce. It's not, it's deadly serious. I want to see this feature in Beryl Compiz.

So please get with the programme.

I find your response rather insulting. WAKE UP take a look around at what is
possible and what is already been done in Linux. I DO have this crappy Madodate
installed on my WinXP. Compared to Metisse, Mindows or Looking Glass, it is childs play.
Do we want a plugin to do similar things in Compcomm? Absolutely... But not in such a
lame manner. When you started this thread and made a comment like
[quote:5c541]
It's the only reason why I've not moved to linux or mac, no-one has this.
[/quote:5c541]
I new you didn't know what you were talking about and never seen the beautiful
things that are already going on in Linux. Having Metisse like features "which by the way
can do the same as Madodate AND MORE" in Compcomm has been on the wish list since
the beggining of Compiz. As far as comments like "you shouldn't be here at all, you just
don't get it", you need to check yourself little boy. You don't know me and i haven't slept
with your mom for you to be insulting me in that manner. Coming in here insulting
people is not a good way to start in an environment you obviously know nothing about.

EDIT: and by the way you think Madodate is soo cool then you obviously haven't seen
the power of Aero Glass in Windows Vista.
http://www.youtube.com/watch?v=1hfKoUWE ... ed&search= (http://www.youtube.com/watch?v=1hfKoUWEdHo&mode=related&search=)

[BillionNamesofGod]

EDIT: and by the way you think Madodate is soo cool then you obviously haven't seen
the power of Aero Glass in Windows Vista.
http://www.youtube.com/watch?v=1hfKoUWE ... ed&search= (http://www.youtube.com/watch?v=1hfKoUWEdHo&mode=related&search=)


can you PLEASE stop this nonsense, and stop flaming.
This thread in particular is about getting a Madodate 3d window beryl/compiz for linux.

IT IS ABOUT NOTHING ELSE. go find some other forum or other idiots if you want to chat about GUIs in general.
So, one and final, please stop your nonsense, don't reply anything but about how to program Madodate 3d into beryl/compiz in this thread, I'm sure you are intelligent enough to do that at least.

If you want to pick this in another generic thread feel free, but not here.

[ianni67]

BillionNamesofGod, would you please, stop shouting to our ears. It's kind of annoying to read your harsh comments. If you prefer windows, go and run windows.

I've been one of the most "annoying" users of this forum, pushing for "perspective windows" similar to those in vista or in looking glass, since the very beginning. Yet, I feel your way is wrong. I don't think coming here and pretending to be "the one" is the best. I think it is the worse. Really.

There are some technical reasons for those "perspective effects" being delayed in OpenCompositing (and in Beryl, too). It has been discussed in all the related forum and also in this one, recently, because of my pushing questions. Those issues are being solved and such effects will be available soon. They are already on the wish-list since monts.

So, please, if you like Linux, sit down and wait or develop (possibly, in accordance with the other developers).

[Kristian]

Please take a look at LG, these kind of things have been suggested NUMEROUS times in the past. And please grow up. Insulting someone who is trying to understand why you are repeating an ancient suggestion is not the way to behave.

[some-guy]

since mettesitte(how do you spell it? :? ) already works on linux, why not modify that into a plugin? ;)

[SmSpillaz]

I really hate bringing this up, but....

This may rely on something called Input Redirection, which will be in the X server very soon. Until then, we cannot do anything of this type because the Texture_From_Pixmap extension does not transform input, so lets say if static window A was to the left of the screen and was animated to the right of the screen as texture B, then all you would see is texture B but you could only click on the 'invisible' texture A and not the texture B because the sever doesnt know its there. This was worked around in the move plugin but it causes high cpu usage and it does not help to much anyways ;-)

So yes you CAN suggest these things and they will eventually happen but not too soon at least ;-)

[Kristian]

I really hate bringing this up, but....

This may rely on something called Input Redirection, which will be in the X server very soon. Until then, we cannot do anything of this type because the Texture_From_Pixmap extension does not transform input, so lets say if static window A was to the left of the screen and was animated to the right of the screen as texture B, then all you would see is texture B but you could only click on the 'invisible' texture A and not the texture B because the sever doesnt know its there. This was worked around in the move plugin but it causes high cpu usage and it does not help to much anyways ;-)

So yes you CAN suggest these things and they will eventually happen but not too soon at least ;-)


There's nothing that says you have to have input redirection for this. The window simply won't have input when it is not in it's natural form, but that's not really the most crucial part of this suggestion.

Also, why would it be necesarry to "work around" input redirection with the move plugin? You have to click the window to initiate the move so no need to redirect that input. At that point, we simply grab the pointer and move the texture around, if the move isn't final until you drop it, has nothing to do with the lack of input redirection. During a move, the display is grabbed anyway, so no dice for input. ... And after all, people have moved windows around since long before Compiz came into the picture and input redirection has never been an issue.

[ianni67]

I'm not sure wether I understood everything: if I did, then I think SmSpillaz is right.
Think of a window representing the output of some application.
As long as I'm dragging it, then there's no point in having its content updated continuously. But if I have the window placed "in perspective", like in LG or in Vista, then I want it updated continuously, because I want to see the output of the application "in real-time". Is this related to input redirection? If it is, then SmSpillaz is right.

uh, SmSpillaz... sorry for bringing out something you hate. But this is something we need to understand in deep. Developers already do, but we are common people.

[Kristian]

I'm not sure wether I understood everything: if I did, then I think SmSpillaz is right.
Think of a window representing the output of some application.
As long as I'm dragging it, then there's no point in having its content updated continuously. But if I have the window placed "in perspective", like in LG or in Vista, then I want it updated continuously, because I want to see the output of the application "in real-time". Is this related to input redirection? If it is, then SmSpillaz is right.

uh, SmSpillaz... sorry for bringing out something you hate. But this is something we need to understand in deep. Developers already do, but we are common people.


You are talking about output, not input. Output is easy, we can do that now, it is allready being redirected. And that's really all you need for this; you aren't going to actually use programs that are tilted 80 degrees; it would be virtually impossible to actually hit whatever you were trying to hit. While it would be neat to have input, it is not something most people would need or even want in this case.

[ianni67]

ok you're definitely right. Sorry for my post.

[BillionNamesofGod]

Hi - am I missing something?

Surely the perspective window doesn't have to update in real-time? There's no point, you just want it out of the way, and anything perspective won't be very clear anyway?


So therefore we don't need input direction? in madodate 3d, the windows don't update in real time in perspective.

Am I right in assuming no-one is going to do this unless the perspective window is updated in real time?

[Fyda]

As Kristian said, we already have what's needed (output redirection) for this effect, and input redirection is irrelevant/unnecessary (unless you really want to try aiming at severely distorted buttons on a perspective window, heh). In short, we can show live window updates while they are transformed; see the Wobbly, Scale, App Switcher, and Window Thumbnails plugins, which take advantage of this.Surely the perspective window doesn't have to update in real-time? There's no point, you just want it out of the way, and anything perspective won't be very clear anyway?Whether or not it needs to update is debatable (perhaps it could be an option), but we already can do it, so why not? People were impressed by how they could watch videos while rotating the cube, or in Scale/Window Thumbnails/App Switcher. It would be conspicuous if the same (basic-seeming) feature weren't in the (hypothetical) implementation of these "perspective windows".

I do agree that it's not useful for actually reading window contents, but it is useful for seeing when something has changed. For example, you may not be able to read the new message someone just sent you, but you can see that there is a new message. And, since you can see the exact window, you know immediately which one to switch to (instead of hunting through Alt+Tab or the Window List). You can simply click on it (a direct representation, rather than an icon or button) to bring it up. That, I think, is worth something. So, live updates couldn't hurt (except, perhaps, on very limited hardware, with many windows open).Am I right in assuming no-one is going to do this unless the perspective window is updated in real time?As was explained, no, we already can do that. So, it's not a reason holding this idea back.

Other important considerations would be "how critical is it to have this feature" and "who can find the time to code this". If you have the knowledge, or know someone who does, then no-one is stopping you. I'm sure a user-contributed plugin would be welcome. It's just that the developers' time is limited (and there's a merge going on). I don't know if anyone would pick this idea up and implement it. That's really up to them.

On to more hypothetical things, about the idea in general:

I've used Madotate, too. While I think it is an attractive approach, I suspect that it is most useful because Windows is (on a default setup) restricted to just the one crowded desktop. I don't know if I would need it on a system with multiple viewports. One could argue that perspective windows can be used instead of viewports, since it offers more visibility of all open windows (whereas windows can be lost/forgotten on neglected viewports).

If this were implemented, we could also try to improve the control scheme. For me, the most frustrating part of both Madotate and Looking Glass 3D was intuitively getting the windows to move to the desired positions. It took too much conscious effort, which is generally not a good thing because one should (from a practical point of view) be focusing on the actual work being done, not on window management. In other words, it should stay out of the user's way, with sane default behaviours. On the other hand, perhaps perspective windows are attractive because one can micro-manage them; I just think there should be a simpler option, for people who want one.

[SmSpillaz]

The lazy way is input redirection :)

Once thats in - you will be able to rotate windows at whatever angle you want in 2D and 3D

[BillionNamesofGod]

As Kristian said, we already have what's needed (output redirection) for this effect, and input redirection is irrelevant/unnecessary (unless you really want to try aiming at severely distorted buttons on a perspective window, heh). In short, we can show live window updates while they are transformed; see the Wobbly, Scale, App Switcher, and Window Thumbnails plugins, which take advantage of this.Surely the perspective window doesn't have to update in real-time? There's no point, you just want it out of the way, and anything perspective won't be very clear anyway?Whether or not it needs to update is debatable (perhaps it could be an option), but we already can do it, so why not? People were impressed by how they could watch videos while rotating the cube, or in Scale/Window Thumbnails/App Switcher. It would be conspicuous if the same (basic-seeming) feature weren't in the (hypothetical) implementation of these "perspective windows".

I do agree that it's not useful for actually reading window contents, but it is useful for seeing when something has changed. For example, you may not be able to read the new message someone just sent you, but you can see that there is a new message. And, since you can see the exact window, you know immediately which one to switch to (instead of hunting through Alt+Tab or the Window List). You can simply click on it (a direct representation, rather than an icon or button) to bring it up. That, I think, is worth something. So, live updates couldn't hurt (except, perhaps, on very limited hardware, with many windows open).Am I right in assuming no-one is going to do this unless the perspective window is updated in real time?As was explained, no, we already can do that. So, it's not a reason holding this idea back.

Other important considerations would be "how critical is it to have this feature" and "who can find the time to code this". If you have the knowledge, or know someone who does, then no-one is stopping you. I'm sure a user-contributed plugin would be welcome. It's just that the developers' time is limited (and there's a merge going on). I don't know if anyone would pick this idea up and implement it. That's really up to them.

On to more hypothetical things, about the idea in general:

I've used Madotate, too. While I think it is an attractive approach, I suspect that it is most useful because Windows is (on a default setup) restricted to just the one crowded desktop. I don't know if I would need it on a system with multiple viewports. One could argue that perspective windows can be used instead of viewports, since it offers more visibility of all open windows (whereas windows can be lost/forgotten on neglected viewports).

If this were implemented, we could also try to improve the control scheme. For me, the most frustrating part of both Madotate and Looking Glass 3D was intuitively getting the windows to move to the desired positions. It took too much conscious effort, which is generally not a good thing because one should (from a practical point of view) be focusing on the actual work being done, not on window management. In other words, it should stay out of the user's way, with sane default behaviours. On the other hand, perhaps perspective windows are attractive because one can micro-manage them; I just think there should be a simpler option, for people who want one.


I think having the perspective windows update in real-time, would be trippy, and if it's possible - well why not?

The general principle is very sound, the desktop just becomes a 3D Cube (or tunnel), and windows are then placed within that "Tunnel".

I can see what you mean about multiple displays, But each display would just have it's depth cube, or one big depth cube, spread accross 2 or 3 displays, the tunnel metaphor does seem to work with many displays. ( Certainly be tricky coding a multiple display version!)

I also see your points about the control scheme, I thought the control scheme for Madotate 3D was remarkable intuitive, as long as you understood the desktop was actually an imaginary tunnel with depth - you could easily move windows in and out (scrool wheel) and drag them to different sides of the cube.

But there's surely room for improvement - windows could just snap to defaults at the sides, with springy actions.

What I've found the idea of treating the desktop like a cube is very good metaphor, and extends well to all other ideas.
For example the recent idea of treating the desktop like a real desktop, with icons stacked up in piles.

Well, you could just use the bottom cube facet as the desktop! Then pike up icons/windows in piles! The sides of the cube just become additional space to "pin" windows on, the top facet acts like a ceiling.

So the desktop becomes a cubical workspace, and been able to pin items on the back and side facets, and the bottem facet acting like a real 3D perspective desktop with icons/windows in piles.

So the the Madotate 3D idea, is very extensible. The approach is clearly the next step in desktop GUI, by actually utilising the space within the cube.